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1 .  The  Object-Oriented  Paradigm 


Most  engineering  disciplines  use  measurement  to  manage  and  control  research  and  development,  to 
monitor  progress  and  the  quality  of  products  under  development,  to  gauge  the  effects  of  decisions  and 
process  changes,  and  to  quantify  the  impacts  of  external  influences.  This  has  not  typically  been  the 
case  for  software  engineering.  However,  the  Software  Program  Managers  Network  (SPMN)  has 
highlighted  as  a  Principle  Best  Practice  the  need  for  more  accurate  and  timely  status  information,  as 
well  as  data  that  will  enable  early  problem  and  risk  identification.  [SPMN]  As  a  result,  there  is  a 
growing  interest  in  the  software  engineering  community  in  applying  measurement  to  software  sys¬ 
tems  via  the  use  of  software  system  metrics. 

Promises  of  great  improvements  in  productivity  and  quality  have  led  many  organizations  to  adopt 
object-oriented  (00)  development  methods.  These  promises  have  been  based  on  the  assumption  that 
significant  reductions  in  development  and  maintenance  costs  are  possible  due  to  the  way  in  which  OO 
systems  are  structured.  Object-based  designs  have  the  potential  to  reduce  the  scope  and  impacts  of 
software  changes  and  to  lead  to  a  greater  capacity  for  reuse.  Such  benefits  are  very  attractive  in  to¬ 
day’s  environment  of  rapidly  evolving  needs  and  decreasing  budgets.  However,  for  most  organiza¬ 
tions  that  have  attempted  it,  the  transition  from  conventional  to  OO  development  has  been  far  from 
trouble  free.  Often,  the  results  have  been  disappointing,  at  times  seeming  to  be  a  step  backward 
rather  than  forward.  In  many  cases,  unrealistic  expectations  are  partially  to  blame;  insufficient  expe¬ 
rience  with  the  00  paradigm  and  lack  of  familiarity  with  the  specific  00  methodology  used  and 
associated  metrics  are  also  contributing  factors. 

The  purpose  of  this  report  is  to  provide  guidance  in  developing  and  using  metrics  for  00  systems. 
This  report  addresses  only  metrics  specific  to  00  development.  It  does  not  address  those  metrics 
common  to  all  developments  independent  of  methodology  used.  As  with  conventional  development, 
metrics  used  in  OO  development  can  be  helpful  not  only  in  providing  information  on  development 
status,  problems,  and  risks,  but  also  in  evaluating  the  effectiveness  of  OO  methods  and  tools  them¬ 
selves.  Measurement  can  be  used  to  track  progress  toward  taking  full  advantage  of  the  OO  paradigm. 
00  metrics  can  help  assess  whether  or  not  OO  methods  are  being  effectively  used  to  facilitate  modi¬ 
fiability  and  reusability.  As  organizations  modify  their  OO  processes  with  the  intent  of  improvement, 
00  metrics  are  needed  to  assess  whether  or  not  intended  improvements  are  indeed  realized. 

Coverage  of  OO  metrics  for  the  full  life  cycle  is  addressed  here;  it  is  not  enough  to  focus  on  detailed 
design  and  code.  The  most  costly  errors  in  software  system  development  originate  in  the  earliest 
activities  and  products,  particularly  in  requirement  analysis  and  architectural  design.  Use  of  a  metrics 
approach  that  addresses  the  progress  and  quality  of  these  activities  and  their  products  can  aid  early 
identification  of  problems  and  risks  and  forestall  the  domino  effect  of  negative  impacts  to  down¬ 
stream  activities  and  products. 

This  report  documents  the  unique  challenges  of  developing  software  using  object-oriented  techniques, 
and  provides  specific  measurements  and  metrics  that  may  be  utilized  for  monitoring  the  development 
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of  object-oriented  software  systems.  In  addition,  this  report  provides  guidance  on  which  metrics 
would  be  useful  during  the  technology  transition  process. 

The  report  consists  of  five  sections  and  four  appendixes.  Following  this  introduction,  Section  2 
defines  metrics  for  the  object-oriented  paradigm  by  providing  a  discussion  of  the  metrics  framework, 
describing  the  unique  attributes  of  the  object-oriented  paradigm  and  providing  justification  for  the 
selection  of  OO-unique  metrics.  Section  3  provides  a  catalog  of  object-oriented  unique  metrics.  Sec¬ 
tion  4  provides  guidance  on  metrics  selection.  Finally,  Section  5  contains  conclusions. 

The  report’s  four  appendixes  contain  supplementary  information.  Appendix  A  provides  formulas  for 
calculating  metrics  presented  in  Section  3.0,  and  Appendix  B  provides  a  list  of  references.  Appendix 
C  provides  background  information  on  OO  techniques.  Appendix  D  provides  guidance  on  acquisition 
and  development  planning  for  metrics  use. 


1.1  HistoricalJustification  for  OO 

The  management  of  software-intensive  systems  is  relatively  new.  During  the  1960s,  the  F-4  Phantom 
used  virtually  no  software  in  its  weapon  systems,  and  software  was  used  sparingly  in  the  DSP  satel¬ 
lite.  During  the  1970s,  the  rapid  evolution  of  sophisticated  electronic  circuitry  resulted  in  smaller 
processors  producing  more  computing  power  for  a  fraction  of  the  cost.  These  advances,  compounded 
by  more  demanding  requirements,  dramatically  increased  DoD’s  software  use.  Figure  1.1-1  repre¬ 
sents  a  summary  of  Air  Force  and  NASA  software  system  size  growth  between  1960  (Vietnam  War) 
and  1995  (post-Gulf  War).  [GSAM] 


Guidelines  fo  Successful  Acquisition  Management  of  Software  Intensive  Systems.  Version  3.0, 
Department  of  the  Air  Force  Software  Technology  Support  Center,  May  2000 


Figure  1.1-1.  Software  complexity  continues  to  increase.  [GSAM] 
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Software  management  technologies  have  been  crucial  in  keeping  up  with  this  explosion  in  software 
capacity.  Software  development  productivity  measured  from  the  start  of  development  through  final 
qualification  test  has  grown  almost  linearly  from  1960  through  the  present.  A  simplified  productivity 
growth  curve  in  Figure  1.1-2  shows  this  growth.  The  result  shows  software  development  productiv¬ 
ity,  increasing  about  one  source  line  per  person-month  per  year  over  the  entire  30-year  period.  [JEN¬ 
SEN]  While  no  new  technology  has  solved  the  software  productivity  problem,  object  technologies 
have  shown  promise  in  improving  the  ability  of  software  development  organizations  to  field  highly 
complex  software  systems. 

In  order  to  determine  which  metrics  will  be  the  most  useful  to  the  object-oriented  developer  a  com¬ 
plete  understanding  of  how  00  techniques  differ  from  traditional  techniques  is  required.  A  historical 
justification  for  the  evolution  to  00  techniques,  a  comparison  between  traditional  and  OO  design 
methodologies,  and  a  discussion  on  OO  lifecycles  is  provided  in  Appendix  C  for  this  purpose. 


1 .2  Definitions  of  Relevant  00  Terminology 

The  set  of  definitions  included  below  have  been  provided  based  on  utilization  in  this  report. 

Aggregate.  An  aggregate  is  (1)  A  class  that  represents  the  “whole”  in  an  aggregation  (whole-part) 
relationship  [OMG].  (2)  A  numeric  value  obtained  by  summing  values  at  lower  levels  in  the  aggre¬ 
gation  structure. 

Ancestor.  The  ancestors  of  a  class  include  its  parent  classes  and  their  ancestor  classes. 
Association.  An  association  is  a  semantic  relationship  between  two  classes. 


Randall  W.  Jenson,  Letter  to  the  Editor,  Crosstalk.  VoI.  13.  No.  8,  August  2000,  p.  30. 
Figure  1.1-2.  Software  productivity  continues  to  increase. 
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Attribute.  An  attribute  is  (1)  A  characteristic  of  a  process,  product,  or  resource.  Some  attributes  can 
be  measured  or  quantified  through  observing  the  product,  process,  or  resource  itself,  or  through 
observing  its  behavior.  Examples  of  attributes  include  size,  completeness,  volatility,  complexity,  and 
traceability.  (2)  A  data  item  that  is  encapsulated  in  a  class  along  with  its  associated  methods. 

Adapted  from  Briand,  Daly,  and  Wiirst  [BRIAND]. 

Child.  In  a  generalization  relationship,  a  child  is  the  specialization  of  the  parent.  A  child  is  also 
called  a  subclass  and  is  a  descendant  class  of  its  parent  classes. 

Class.  A  class  is  a  structure  for  OO  development  that  encapsulates  data  (attributes)  and  functions 
(methods).  [BRIAND]  Design  requirements  are  allocated  to  classes. 

Class  Category.  A  class  category  is  a  logical  collection  of  classes,  some  of  which  are  visible  to  other 
class  categories  and  others  of  which  are  hidden.  The  classes  in  a  class  category  collaborate  to  provide 
a  set  of  services.  [BOOCH] 

Complexity.  Cyclomatic  complexity  is  a  measure  of  the  complexity  of  a  module's  decision  structure. 
It  is  the  number  of  linearly  independent  paths  and,  therefore,  the  minimum  number  of  paths  that 
should  be  tested  [MCCABE]. 

Dependency.  A  dependency  is  a  relationship  between  two  modeling  elements  in  which  a  change  to 
one  element  (the  independent  element)  affects  the  other  element  (the  dependent  element). 

Descendant.  The  descendants  of  a  class  include  its  child  classes  and  their  descendant  classes. 

Inheritance.  Inheritance  is  the  mechanism  by  which  specific  classes  incorporate  the  structure  and 
behavior  of  more  general  ancestor  classes.  Adapted  from  Object  Management  Group  [OMG]. 

Method.  A  method  is  a  procedure  or  function  that  is  encapsulated  in  a  class  with  its  related  data 
(attributes).  Other  names  for  method  include  Operation,  Service,  and  Member  Function.  Adapted 
from  Briand,  Daly,  and  Wiirst  [BRIAND]. 

Object.  An  object  is  an  instance  of  a  class  that  has  a  well-defined  boundary  and  identity  that  encap¬ 
sulates  state  and  behavior.  Adapted  from  Object  Management  Group  [OMG]. 

Object-Oriented  Analysis  (OOA).  Object-oriented  analysis  is  a  methodology  of  analysis  in  which 
requirements  and  potential  high-level  system  structure  are  examined  from  the  perspective  of  the 
classes  and  objects  found  in  the  vocabulary  of  the  problem  domain.  Adapted  from  Booch  [BOOCH]. 

Object-Oriented  Design  (OOD).  Object-Oriented  Design  is  a  methodology  of  design  in  which  sys¬ 
tem  design  is  expressed  in  terms  of  classes  and  objects  from  the  problem  domain  and  relationships 
between  these  classes  and  objects.  OOD  results  in  models  of  the  system  under  design;  each  model 
may  be  depicted  by  one  or  more  diagrams  that  show  structural,  behavioral,  and  interface  characteris¬ 
tics  of  the  system. 
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Object-Oriented  (00)  Development.  Object-oriented  development  is  development  in  which  object- 
oriented  analysis,  object-oriented  design,  and  object-oriented  programming  methodologies  are  used  to 
produce  software  implementations.  Note  that  some  “object-oriented”  development  efforts  may 
choose  to  use  one  or  more  of  00 A,  OOD,  or  OOP,  but  not  others. 

Object-Oriented  Programming  (OOP).  Object-oriented  programming  is  an  implementation  method¬ 
ology  in  which  programs  are  organized  as  cooperative  collections  of  objects,  each  of  which  represents 
an  instance  of  some  class,  and  whose  classes  are  all  members  of  a  hierarchy  of  classes  united  via 
inheritance  relationships.  [BOOCH] 

Parent.  In  a  generalization  relationship,  a  parent  is  a  generalization  of  another  element,  the  child.  A 
parent  is  also  called  a  superclass  and  is  an  ancestor  class  of  its  child  classes. 

Use  Case.  A  description  of  a  set  of  related  sequences  of  actions  (scenarios),  including  variants,  that  a 
system  performs  that  yields  an  observable  result  of  value  to  a  particular  actor  (paraphrased  from 
Jacobson,  Booch,  and  Rumbaugh  [JACOBSON]).  Functional  requirements  are  allocated  to  use  cases. 

Scenario.  A  scenario  is  a  specific  sequence  of  actions  that  illustrates  behavior.  [JACOBSON]  Also, 
a  scenario  is  a  specific  instance  of  a  use  case. 
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2.  Metrics  for  Use  with  Object-Oriented  Techniques 


2.1  Overview  of  the  Metrics  Framework 

The  information  presented  in  this  section  is  a  brief  description  of  the  framework  described  in  Section 
2.0  (Tailoring  Software  Measures)  of  the  Practical  Software  Measurement  (PSM).  The  PSM  guide¬ 
book  is  an  extensive  reference  that  describes  how  to  define  and  implement  a  software  measurement 
process  to  support  the  information  needs  of  software-intensive  acquisition  and  development.  The 
PSM  guidebook  defines  a  Metrics  framework  that  consists  of  6  interrelated  software  issues.  Issues 
are  defined  as  real  or  potential  obstacles  to  the  achievement  of  project  objectives.  These  6  issues  are 
then  used  to  organize  specific  metrics  into  categories.  This  report  extends  the  metric  categories  and 
the  metrics  to  include  information  pertinent  to  the  00  software  developer. 

The  PSM  guidebook  groups  software  into  six  interrelated  issues  (see  Figure  2.1-1)  that  are  common 
to  all  projects.  These  six  issues  are  defined  in  the  “Practical  Software  Measurement”  metrics  guide¬ 
book  and  summarized  below  [PSM]. 


“Practical  Software  Measurement”,  Office  of  the  Under  Secretary  of  Defense  for 
Acquisition  and  Technology  Joint  Logistics  Commanders  Joint  Group  on  Systems 
Engineering  (OUSD  A&T  JGSE),  Version  3.1a,  April  1998. 


Figure  2.1-1.  Interrelationship  of  metrics  issues. 
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Schedule  and  Progress  -  This  issue  relates  to  the  completion  of  major  milestones  and  individual 
work  units.  A  project  that  falls  behind  schedule  usually  can  make  delivery  only  by  eliminating  func¬ 
tionality  or  sacrificing  quality. 

Project  Resources  -  This  issue  relates  to  the  balance  between  the  work  to  be  performed  and  person¬ 
nel  resources  assigned  to  the  project.  A  project  that  exceeds  the  budgeted  effort  usually  can  recover 
only  by  reducing  software  functionality  or  sacrificing  quality. 

Growth  and  Stability  -  This  issue  relates  to  the  stability  of  the  functionality  or  capability  required  of 
the  software.  It  also  relates  to  the  volume  of  software  delivered  to  provide  the  required  capability. 
Stability  includes  changes  in  scope  or  quantity.  An  increase  in  software  size  usually  requires 
increasing  the  applied  resources  or  extending  the  project  schedule. 

Product  Quality  -  This  issue  relates  to  the  ability  of  the  delivered  software  product  to  support  the 
user’s  needs  without  failure.  When  poor  quality  product  is  developed,  the  burden  of  making  it  work 
usually  falls  on  the  sustaining  engineering  organization. 

Development  Performance  -  This  issue  relates  to  the  capability  of  the  developer  relative  to  project 
needs.  A  developer  with  a  poor  software  development  process  or  low  productivity  may  have  diffi¬ 
culty  meeting  aggressive  schedule  and  cost  objectives.  More  capable  software  developers  are  better 
able  to  deal  with  project  changes. 

Technical  Adequacy  -  This  issue  relates  to  the  viability  of  the  proposed  technical  approach.  It 
includes  features  such  as  software  reuse,  use  of  COTS  software  and  components,  and  reliance  on 
advanced  software  development  processes.  Cost  increases  and  schedule  delays  may  result  if  key  ele¬ 
ments  of  the  proposed  technical  approach  are  not  achieved. 

These  common  software  issues  can  be  used  in  two  ways.  First,  the  common  software  issues  are  used 
to  classify  project-specific  issues  identified  via  risk  analysis  or  other  means  so  that  they  can  be 
mapped  into  the  measurement  selection  structure.  Second,  reviewing  the  common  software  issues 
helps  both  the  acquirer  and  the  developer  to  check  that  all  potential  issue  areas  have  been  considered. 
[PSM] 

Once  the  project-specific  issues  have  been  identified,  appropriate  measures  must  be  selected  to  track 
them.  A  measure  is  a  quantification  of  a  characteristic  or  attribute  of  a  software  process  or  product  or 
resource.  Many  different  measures  may  apply  to  an  issue.  However,  in  most  cases  it  is  not  practical 
to  collect  all  or  even  most  of  the  possible  measures  for  an  identified  issue.  Generally,  more  measures 
should  be  collected  to  track  the  high-priority  issues.  Identification  of  the  “best”  set  of  measures  for  a 
project  depends  on  a  systematic  evaluation  of  the  potential  measures  with  respect  to  the  issues  and 
relevant  project  characteristics.  Section  4.0  of  this  report  on  metrics  selection  provides  additional 
guidance  on  this  topic. 

A  measurement  category  is  a  set  of  related  measures.  The  measures  within  a  category  address  related 
software  attributes.  They  provide  similar  information  and  answer  similar  questions  about  an  issue.  A 
number  of  measurement  categories  for  each  software  issue  are  identified  in  Figure  2.1-2,  which  lists 
the  categories  for  each  issue. 
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—  Lines  of  Code 
--  Components 

—  Words  of  Memory 

—  Database  Size 
Requirements 

|—  Function  Points 
^  Change  Request  Workload 


H  CMM  Level 
[—  Product  Size/ 
Effort  Ratio 
Functional  Size/ 
Effort  Ratio 


-Effort 

—Staff  Experience 
—Staff  Turnover 

—  Earned  Value 
—Cost 

—  Resource 
—Availability  Dates 

Resource  Utilization 


~  Problem  Reports 

-  Defect  Density 

-  Failure  Interval 

-  Complexity 
^  Rework  Size 

-  Rework  Effort 


-  Milestone  Dates 

-  Component  Status 

-  Test  Case  Status 

-  Paths  Tested 

-  Problem  Report 
Status 

-  Reviews  Completed 

-  Change  Request 
Status 

*-  Build  Content 
•Component 
•Functionality 


-  CPU  Utilization 

~  CPU  Throughput 

-  I/O  Utilization 

-  I/O  Throughput 

”  Memory  Utilization 

-  Storage  Utilization 
“  Response  Time 

-  Requirements 
Accuracy 

-  Impact  of  new 
technology 


“Practical  Software  Measuremenf,  Office  of  the  Under  Secretary  of  Defense  for  Acquisition  and 
Technology  Joint  Logistics  Commanders  Joint  Group  on  Systems  Engineering  (OUSD  A&T  JGSE) , 
Version  3.1a,  April  1998. 


Figure  2.1-2.  Software  issue  to  category  mapping. 


2.2  Selection  and  Justification  of  OO-Unique  Metrics 

While  this  report’s  focus  is  on  OO,  it  is  important  to  recognize  that  conventional  and  OO  develop¬ 
ments  have  many  features  in  common.  A  software  development  project  utilizing  the  OO  design 
methodology  and  life  cycle  has  the  same  software  development  issues  as  does  a  conventional  project. 
The  following  metrics  have  been  selected  for  inclusion  in  this  report  based  on  an  analysis  of  the 
similarities  and  differences  between  OO  developments  and  traditional  development.  The  contrast 
between  OO  and  traditional  development  is  documented  in  appendix  C. 

All  of  the  attributes  in  the  three  common  software  issues  of  Development  Performance,  Technical 
Adequacy,  and  Project  Resources  remain  the  same;  that  is  to  say,  the  metrics  for  these  issues  are 
exactly  the  same  in  OO  as  in  conventional  software  development.  The  categories  described  in  the 
three  common  software  issues  of  Growth  and  Stability,  Product  Quality,  and  Schedule  and  Progress 
are  slightly  different.  This  relationship  is  summarized  in  Figure  2.2-1  and  can  be  contrasted  with 
Figure  2.1-1.  The  issues  highlighted  in  black  are  those  of  interest  to  the  OO  developer. 

A  number  of  measurement  categories  have  been  added  and  modified  as  a  result  of  the  use  of  OO 
techniques.  These  are  summarized  in  Figures  2.2-2, 2.2-3,  and  2.2-4.  The  numbers  circled  in  black 
on  each  of  these  figures  uniquely  identify  the  measurement  categories  that  have  been  modi- 


Figure  2.2-1.  Interrelationships  of  OO  metrics  issues. 


transition 


—  Lines  of  Code 

—  Components 

—  Words  of  Memory 

—  Database  Size 

—  Requirements  Volatility 

—  Function  Points 

—  Change  Request  Workload 


—  Lines  of  Code 

—  Size  O 

—  Words  of  Memory 

—  Database  Size 

—  Requirements  Volatility 

—  Function  Points 

—  Change  Request  Workload 

—  Design  Volatility 


Figure  2.2-2.  Software  OO  issue  to  category  mapping  for  Growth  and  Stability. 


-  Problem  Reports 

-  Defect  Density 

-  Failure  Interval 
”  Complexity 

-  Rework  Size 
Rework  Effort 


transition 


—  Problem  Reports 

—  Defect  Density 

—  Failure  Interval 

—  Complexity 

—  Rework  Size 

—  Rework  Effort 

—  Inheritance 

—  Object  Structure 
Coupling 


Figure  2.2-3.  Software  OO  issue  to  category  mapping  for  Product  Quality. 
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--  Milestone  Dates  (SSR, 
PDR,  CDR) 

-  Component  Status 
-.Test  Case  Status 

-  Paths  Tested 

-  Problem  Report  Stal 

-  Reviews  Completed 

-  Change  Request 
Status 

^  Build  Content 
•Component 
•Functionality 


—  Milestone 
—Class  Status 

—  Use  Case  Status  ^ 

—  Paths  Tested 
Problem  Report  Status 

—  Reviews  Completed 
“  Change  Request 

Status 

—  Build  Content 
•Classes 
•Use  Cases 


Figure  2.2-4.  Software  OO  issue  to  category  mapping  for  Schedule  and  Progress. 


fied  or  added  and  that  are  of  particular  interest  to  the  OO  developer.  These  identifying  numbers  are 
one-to-one  traceable  to  the  metrics  described  in  Section  3.0,  Catalog  ofOO  Unique  Metrics. 


The  three  measurement  categories  selected  for  addition/modification  in  the  Growth  and  Stability  issue 
are  the  Size,  Requirements  Volatility,  and  Design  Volatility  measurement  categories.  Each  of  these 
relies  on  measurement  values  that  are  uniquely  described  in  the  OO  techniques.  The  size  metric, 
depending  on  the  phase  of  the  program,  is  defined  by  use-cases  and  class  definitions.  Requirement 
Volatility  is  measured  in  Use-Cases,  and  Design  Volatility  is  measured  in  Classes. 

The  three  measurement  categories  selected  for  inclusion  in  the  OO  Product  Quality  category  are 
Inheritance,  Object  Structure,  and  Coupling.  These  three  measurement  categories  are  new  to  the  met¬ 
rics  framework. 


Five  measurement  categories  have  been  selected  for  modification  and  inclusion  in  the  OO  Schedule 
and  Progress  category.  These  include:  Milestone,  Class  Status,  Use-Case  Status,  and  Build  Content 
-  classes  and  use  cases.  The  modified  measurement  category  is  the  Milestone  metric.  In  general,  this 
measurement  category  has  been  modified  to  reflect  an  evolutionary  terminology  in  the  milestone 
titles.  The  remaining  four  metrics  are  new  to  the  metrics  framework. 


*  The  concept  of  Application  Size  and  Method  Size  is  discussed  in  LORENZ.  ROSENBERG  summarizes  some  of  the 
metrics  described  in  LORENZ,  and  CHIDAMBER  and  maps  the  metrics  to  a  set  of  quality  critiera,  including:  Classes, 
Message,  Cohesion,  Coupling  and  Inheritance. 

^  Metrics  for  Class  Inheritance,  Method  and  Class  Internals,  and  Class  Externals  are  discussed  in  LORENZ.  CHIDAMBER 
provides  information  pertaining  to  the  rationale  for  the  use  of  the  Weighted  Methods  per  Class,  Depth  of  Inheritance  Tree, 
Number  of  Children,  Coupling  between  Object  Classes,  Response  for  Class,  and  Lack  of  Cohesion  in  Methods  metrics. 
ROSENBERG  summarizes  some  of  the  metrics  described  in  LORENZ  and  CHIDAMBER  and  maps  the  metrics  to  a  set  of 
quality  critiera,  including:  Classes,  Message,  Cohesion,  Coupling,  and  Inheritance. 

^  Metrics  for  Scheduling  are  discussed  in  LORENZ. 
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3.  Catalog  of  Recommended  00  Unique  Metrics 


The  recommended  Object-Oriented  Metrics  consist  of  the  set  of  31  metrics  identified  in  Table  3-1. 
These  metrics  were  selected  by  first  performing  an  analysis  of  the  differences  between  traditional 
design  methodology  and  Object-Oriented  methodologies.  These  differences  were  then  used  to  iden¬ 
tify  common  issues  in  the  PSM  metrics  framework  [PSM]  where  metrics  information  would  be 
unique  to  an  Object-Oriented  development.  Once  this  was  accomplished,  relevant  metrics  suitable  to 
fill  in  the  metrics  framework  were  identified  based  on  an  industry  literature  search  and  the  author’s 
experiences.  This  analysis  is  summarized  in  Section  2.0,  Metrics  for  use  with  Object-Oriented 
Techniques. 

The  metrics  described  in  the  following  sections  are  organized  by  common  issues  and  metrics  catego¬ 
ries.  This  organization  is  similar  to  that  found  in  the  PSM  framework.  Each  metric  description  con¬ 
sists  of  a  table  describing  the  metric  and  an  example  metric  report  that  indicates  how  the  metric  could 
be  represented.  The  metric  table  contains  information  on  how  the  metric  fits  into  the  Metrics  Frame¬ 
work,  a  description  of  the  measurements  that  make  up  the  metric  and  how  these  are  calculated,  a  dis¬ 
cussion  of  the  key  principles  related  to  the  metric,  a  discussion  of  the  example  graphic,  and  some 
“rules  of  thumb”  for  use  during  metrics  analysis.  Further  information  on  general  metrics  analysis 
topics  can  be  obtained  from  the  PSM  Part  4,  Applying  Software  Measures  [PSM].  In  each  of  the  sub¬ 
sequent  charts,  the  acronym  CRP  stands  for  Current  Reporting  Period.  Calculations  for  each  of  the 
example  metrics  described  in  this  section  are  provided  in  Appendix  A.  The  numbers  circled  in  black 
in  Table  3-1  are  one-to-one  traceable  to  the  justification  for  the  metric  described  in  Section  2.2, 
Selection  and  Justification  of  00  unique  Metrics. 

A  Note  on  Thresholds 

Many  of  the  metrics  diagrams  provided  in  the  following  sections  contain  thresholds.  These 
thresholds  have  been  provided  as  guidance  only  and  are  based  on  either  (1)  published  best 
practices  or  (2)  the  experiences  of  the  author.  All  thresholds  are  to  be  applied  at  the  discre¬ 
tion  of  the  reader,  no  threshold  value  is  absolute,  and  all  threshold  values  are  subject  to  tai¬ 
loring.  It  is  the  author’s  opinion,  however,  that  where  thresholds  are  supplied  in  the  metrics 
diagrams,  they  should  be  incorporated  as  part  of  the  metrics  program,  as  tailored  by  the 
using  organization.  The  application  of  thresholds  is  to  ensure  that  some  action  is  taken  when 
a  threshold  is  exceeded.  When  thresholds  do  not  exist,  there  is  no  indication  of  what  would 
be  considered  “good”  or  “bad,  ”  and,  therefore,  no  indication  of  when  action  needs  to  be 
considered. 
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Table  3- 1 .  Object-Oriented  Metrics 


ISSUE 

[category 

RECOMMENDED  METRICS 

Growth  and 
Stability 

m 

Plan  vs  Actual  Use  Cases  Completed 

Plan  vs  Actual  Classes  Completed 

Number  of  Attributes  In  a  Class 

Number  of  Methods  in  a  Class 

Number  Scenarios  in  a  Use  Case 

Added,  Deleted  and  Modified  Use  Cases 

1^ 

Added,  Deleted  and  Modified  Classes 

Added,  Deleted  and  Modified  Methods 

Added,  Deleted  and  Modified  Attributes 

Product 

Quality 

Inheritance 

Number  of  Children  per  Class 

Depth  of  Inheritance  Tree  per  Class 

Object  Structure 

Weighted  Methods  per  Class 

Type  of  Methods  In  Class 

Coupling 

Coupling  Between  Classes 

Response  for  a  Class 

Schedule 

and 

Milestone 

Plan  vs  Actual  Milestone  Days 

Milestone  Slip  Ratio 

Progress 

■ 

Plan  vs  Actual  Classes  Completed 

Plan  vs  Actual  Methods  Completed 

Plan  vs  Actual  Attributes  Completed 

Class  Traceability  Status 

Integration  Test  Traceability  Status 

Plan  vs  Actual  Classes  that  have  Successfully  Passed  Integration  Test 

Plan  vs  Actual  Use  Cases  Completed 

Use  Case  Traceability  Status 

Functional  Test  Traceability  Status 

Plan  vs  Actual  Use  Cases  that  have  Successfully  Passed  Functional  Test 

Build  Content  - 
Classes 

Plan  vs  Actual  Classes  in  Build 

Ratio  of  Classes  In  Build 

Plan  vs  Actual  Use  Cases  In  Build 

Ratio  of  Use  Cases  In  Build 

3.1  Growth  and  Stability 

The  numbers  circled  in  black  in  Table  3.1-1  are  one-to-one  traceable  to  the  justification  for  the  metric 
described  in  Section  2.2,  Selection  and  Justification  of  OO  unique  Metrics. 

Table  3.1-1  identifies  each  of  the  metrics  selected  for  Growth  and  Stability. 


Table  3.1-1  Growth  and  Stability  OO  Metrics 


ISSUE 

CATEGORY 

RECOMMENDED  METRICS 

Growth  and 
Stability 

Size 

Plan  vs  Actual  Use  Cases  Completed 

Plan  vs  Actual  Classes  Completed 

Number  of  Attributes  In  a  Class 

Number  of  Methods  In  a  Class 

Number  Scenarios  in  a  Use  Case 

Requirements 

Volatility 

Added,  Deleted  and  Modified  Use  Cases 

Design  Volatility 

Added,  Deleted  and  Modified  Classes 

Added,  Deleted  and  Modified  Methods 

Added,  Deleted  and  Modified  Attributes 
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3.1.1  Size 

Size  measures  the  physical  size  of  a  software  product.  Product  size  is  a  critical  factor  for  estimating 
development  schedule  and  cost.  Size  measures  also  provide  information  about  the  amount  and 
frequency  of  change  to  a  software  product,  which  is  especially  critical  late  in  the  development. 
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3.1 .1.1  Plan  versus  Actual  Use  Cases  Completed 


Growth  and  Stability 


Issue 

Category 

Measure 


Description 


Example 

Graph 

Performance 

Analysis 


Planned  number  of  use  cases  to  be  completed  during  the  CRP 
Actual  number  of  use  cases  completed  during  the  CRP 

Calculate  cumulative  number  of  use  cases  planned  to  be  complete  (ref.  App.  A,  (a)) 
Calculate  cumulative  number  of  use  cases  actually  completed  (ref.  App.  A,  (a)) 

Use  cases  describe  the  functionality  required  of  the  system  based  on  the  user  view¬ 
point.  The  number  and  magnitude  of  the  use  cases  defined  for  a  particular  applica¬ 
tion  then  becomes  an  indicator  of  software  size.  Unplanned  additions  and  changes 
to  the  number  and  magnitude  of  use  cases  can  adversely  influence  schedules  and 

costs. _ _ _ _ _ _ _ 

A  line  chart  combined  with  a  bar  chart  (Figure  3.1-1)  is  used  to  present  the  size 
information.  The  information  presented  includes  the  planned  number  of  use  cases 
and  the  actual  number  of  use  cases  plotted  over  time.  A  cumulative  value  is 
included  in  the  line  chart  and  a  CRP  plan/actual  is  provided  in  the  bar  charts. 


Actual  values  should  track  to  the  plan.  Deviations  of  actuals  above  the  plan  line 
indicate  that  more  is  being  accomplished  than  was  originally  projected.  Deviations 
of  actuals  below  the  plan  line  indicate  that  less  is  being  accomplished  than  origi- 


nallv  Droiected 


:2  weeks  week  4  weeks  week  6  week?  weeks  weeks  week  10  week  n  weekly 

746  10  64731  1 

6378957321 
15  19  25  35  41  45  52  55  56  57 

10  13  20  28  37  42  49  52  54  55 


3.1 .1 .2  Plan  versus  Actual  Classes  Completed 


Issue 

Growth  and  Stability 

Category 

Size 

Measure 

Planned  number  of  classes  to  be  completed  during  the  CRP 

Actual  number  of  classes  completed  during  the  CRP 

Calculate  cumulative  number  of  classes  planned  to  be  complete  (ref,  App.  A,  (b)) 
Calculate  cumulative  number  of  classes  actually  completed  (ref,  App.  A,  (b)) 

Description 

This  indicator  provides  an  estimate  of  software  size  in  terms  of  design  components. 
Unplanned  additions  and  changes  to  the  number  and  magnitude  of  classes  can 
adversely  influence  schedules  and  costs. 

Example 

Graph 

A  line  chart  combined  with  a  bar  chart  (Figure  3.1-2)  is  used  to  present  the  size 
information.  The  information  presented  includes  the  planned  number  of  classes 
and  the  actual  number  of  classes  plotted  over  time.  A  cumulative  value  is  included 
in  the  line  chart  and  a  CRP  plan/actual  is  provided  in  the  bar  charts. 

Performance 

Analysis 

Actual  values  should  track  to  the  plan.  Deviations  of  actuals  above  the  plan  line 
indicate  that  more  is  being  accomplished  than  was  originally  projected.  Deviations 
of  actuals  below  the  plan  line  indicate  that  less  is  being  accomplished  than  origi¬ 
nally  projected. 

week  1 

week  2 

week  3 

week  4 

week  5 

week  6 

week  7 

week  8 

week  9 

week  10 

week  1 1 

week  12 

Plan  5 

7 

10 

6 

8 

12 

8 

6 

9 

5 

2 

1 

Actual  4 

5 

8 

5 

9 

12 

11 

6 

9 

4 

3 

2 

Cum  Plan  5 

12 

22 

28 

36 

48 

56 

62 

71 

76 

78 

79 

Cum  Act  4 

9 

17 

22 

31 

43 

54 

60 

69 

73 

76 

78 

Plan  vs  Actual  Classes  Completed 
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Figure  3.1-2.  Plan  versus  actual  classes  completed. 
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3.1 .1 .3  Number  of  Attributes  in  a  Class 


Issue 

Growth  and  Stability 

Category 

Size 

Measure 

CRP  number  of  attributes  in  each  class 

CRP  number  of  classes 

Calculate  cumulative  number  of  classes/  cumulative  number  of  attributes  (ref.  App. 
A,  (c)) 

Calculate  CRP  number  of  classes/  CRP  number  of  attributes  (ref.  App.  A,  (c)) 

Description 

The  number  of  attributes  in  a  class  is  one  measure  of  its  size.  A  class  that  has  mul¬ 
tiple  data  objects  may  indicate  that  the  class  has  a  number  of  unnecessary  special¬ 
ized  relationships  with  other  classes  in  the  system.  Lower  threshold  calculated 
value  should  not  be  below  50%. 

Example 

Graph 

A  line  chart  combined  with  a  bar  chart  (Figure  3.1-3)  is  used  to  present  the  size 
information.  The  information  presented  includes  the  cumulative  ratio  value  of 
attributes  in  a  class.  This  is  augmented  by  a  bar  chart  indication  of  the  CRP  ratio 
value.  Lower  thresholds  are  indicated  on  the  chart  as  well. 

Performance 

Analysis 

A  large  number  of  attributes  in  a  class  are  an  indication  that  the  class  may  be  doing 
too  much.  For  values  falling  below  the  threshold,  the  unique  class  may  be  unneces¬ 
sary.  Review  the  system  classes  for  optimization  through  combination. 
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Figure  3.1-3.  Number  of  attributes  per  class. 


3.1. 1.5  Number  of  Scenarios  in  a  Use  Case 


Issue 

Growth  and  Stability 

Category 

Size 

Measure 

CRP  number  of  use  cases 

CRP  number  of  scenarios  per  use  case 

Calculate  CRP  number  of  uses  cases/  CRP  number  of  scenarios  (ref.  App.  A,  (e)) 
Calculate  cumulative  number  of  use  cases/  cumulative  number  of  scenarios  (ref. 
App.  A,  (e))  _ _ _ : — ^ - 

Description 

The  number  of  scenario  scripts  is  an  indication  of  the  size  of  the  application  to  be 
developed.  The  number  of  scenario  scripts  also  relates  to  the  number  of  test  cases 
that  must  be  written  to  fully  exercise  the  system.  Upper  value  threshold  should  not 
exceed  60%.  Lower  value  threshold  should  not  exceed  40%. 

Example 

Graph 

A  line  chart  combined  with  a  bar  chart  (Figure  3.1-5)  is  used  to  present  the  size 
information.  The  information  presented  includes  cumulative  ratio  value  of  scenar¬ 
ios  in  use  case.  This  is  augmented  by  a  bar  chart  indication  of  the  CRP  ratio  value. 
Thresholds  are  indicated  on  the  chart  as  well. 

Performance 

Analysis 

The  number  of  scenarios  in  a  use  case  is  an  indication  of  user  functionality  pro¬ 
vided.  A  scenario-to-use-case  ratio  that  falls  above  the  60%  threshold  is  an  indica¬ 
tion  that  too  much  functionality  is  being  described  in  a  single  use  case.  An  attempt 
should  be  made  to  simplify  the  design.  Should  this  value  fall  below  the  indicated 
40%  threshold,  the  use  cases  should  be  reviewed  for  optimization  opportunities. 
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Figure  3. 1-5.  Number  of  scenarios  per  use  case. 


3.1.2  Requirements  Volatility 

Use  Case  volatility  measures  the  stability  of  the  required  functionality  of  a  software  product.  Use 
case  volatility  may  be  used  to  estimate  development  schedule  and  cost.  This  measure  provides 
information  about  the  amount  and  frequency  of  change  to  software  functionality,  which  is  especially 
critical  late  in  the  development.  Use  case  volatility  generally  correlates  with  effort,  cost,  schedule, 
and  product  size  changes. 

Many  of  the  volatility  metrics  rely  on  a  “base”  size  value  being  included  in  the  calculations.  The 
“base”  value  is  used  as  the  basis  on  which  the  requirements  design  or  code  will  be  modified.  This 
concept  is  necessary  for  use  with  incremental,  evolutionary,  or  reuse-driven  developments  as  the 
requirements,  design,  and  code  are  not  being  written  from  scratch  but  rely  on  existing  products  for 
modification.  The  “base”  value  is  that  portion  of  the  integrated  software  product  that  would  be  con¬ 
sidered  pre-existing.  During  the  initial  iteration  of  the  product  life  cycle  for  newly  developed  soft¬ 
ware,  this  value  would  be  set  to  zero. 

The  chum  ratios  calculated  on  the  subsequent  metrics  charts  reflect  a  normalized  numeric  value  asso¬ 
ciated  with  how  much  of  the  product  has  been  modified  over  time.  A  chum  ratio  approaching  1 
reflects  that  the  product  has  been  designed  more  than  once.  This  can  be  misleading  due  to  the  fact 
that  you  can  have  components  of  the  product  that  are  designed  many  times,  whereas  other  portions  of 
the  product  may  have  only  been  designed  once. 
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3.1 .2.1  Added,  Deleted  and  Modified  Use  Cases 

Growth  and  Stability _ 

Requirements  Volatility 


Issue 

Category 


Measure 


Description 


Example 

Graph 

Performance 

Analysis 


CRP  planned  number  of  use  cases 
CRP  actual  base  number  of  use  cases 
CRP  actual  added  number  of  use  cases 
CRP  actual  deleted  number  of  use  cases 

CRP  modified  number  of  use  cases  (which  includes  all  changed  aspects  of  the  use 
case  definition) 

Calculate  cumulative  planned  number  of  use  cases  (ref.  App.  A,  (f)) 

Calculate  cumulative  actual  number  of  use  cases  (ref.  App.  A,  (f)) 

Calculate  churn  ratio  (scaled  ratio  of  CRP  modified  use  cases  to  cummulative 
actual  use  cases)  (ref.  App.  A,  (f 


Plan 
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Figure  3.1-6.  Added,  deleted  and  modified  use  cases. 
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3.1.3  Design  Volatility 

Class  volatility  measures  the  stability  of  the  design  of  a  software  product.  Class  volatility  can  be  used 
to  estimate  downstream  testing  and  rework  costs.  Method/attribute  volatility  measures  the  stability  of 
a  software  product.  These  measures  provide  information  about  the  amount  and  frequency  of  change 
to  software  design,  which  is  especially  critical  late  in  the  development.  Method/attribute  and  class 
volatility  generally  correlates  to  effort,  cost,  schedule,  and  product  size  changes. 

See  paragraph  3.1.2  for  a  description  of  the  concepts  of  “base”  and  “chum  ratio.” 
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3.1 .3.1  Added,  Deleted  and  Modified  Ciasses 


Issue 

Growth  and  Stability 

Category 

Design  Volatility 

Measure 

CRP  planned  number  of  classes 

CRP  actual  base  number  of  classes 

CRP  actual  added  number  of  classes 

CRP  actual  deleted  number  of  classes 

CRP  modified  number  of  classes  (which  includes  all  changed  aspects  of  the  class 
definition) 

Calculate  cumulative  planned  number  of  classes  (ref.  App.  A,  (g)) 

Calculate  cumulative  actual  number  of  classes  (ref.  App.  A,  (g)) 

Calculate  churn  ratio  (scaled  ratio  of  modified  classes  to  base)  (ref  App.  A,  (g)) 

Description 

This  indicator  can  be  used  to  monitor  changes  to  design  throughout  a  project, 
which  can  serve  as  a  leading  indictor  of  delays,  cost  increases  and  rework.  The 
churn  ratio  is  provided  as  an  indicator  of  the  amount  of  rework  being 
accomplished. 

Example 

Graph 

A  line  chart  combined  with  a  bar  chart  (Figure  3.1-7)  is  used  to  present  the  volatil¬ 
ity  information.  The  information  presented  includes  the  cumulative  number  of 
classes.  This  is  augmented  by  a  bar  chart  indication  of  the  number  of  CRP  modi¬ 
fied.  added  and  deleted  classes. 

Performance 

Analysis 

A  high  level  of  class  volatility  may  require  adjustment  to  current  resource  alloca¬ 
tions,  effort  estimates,  budgets,  and  schedule.  The  churn  ratio  should  be  consistent 
with  the  system  phase.  (Sometimes  it  is  a  measure  of  rework,  other  times  expected 
work.)  In  addition,  adding  and  deleting  of  classes  late  in  a  project  could  indicate  an 
unstable  design  process. 
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Added,  Deleted  and  Modified  Classes 
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Figure  3.1-7.  Added,  deleted  and  modified  classes. 
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Performance 

Analysis 


cations,  effort  estimates,  budgets,  and  schedule.  The  chum  ratio  should  be  consis¬ 
tent  with  the  system  phase.  (Sometimes  it  is  a  measure  of  rework,  other  times 
expected  work.)  In  addition,  adding  and  deleting  of  methods  late  in  a  project  could 
indicate  an  unstable  design  process. _ 
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Figure  3.1-8.  Added,  deleted  and  modified  methods. 
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3-1 .3.3  Added, 


Issue 

Category 

Measure 


Description 


Example 

Graph 


Deleted  and  Modified  Attributes 

Growth  and  Stability _ 

Design  Volatility 


CRP  planned  number  of  attributes 
CRP  actual  base  number  of  attributes 
CRP  actual  added  number  of  attributes 
CRP  actual  deleted  number  of  attributes 

CRP  actual  modified  number  of  attributes  (which  includes  all  changed  aspects  of 
the  attribute  definition) 

Calculate  cumulative  planned  number  of  attributes  (ref.  App.  A,  (k)) 

Calculate  cumulative  actual  number  of  attributes  (ref.  App.  A,  (k)) 

Calculate  churn  ratio  (scaled  ratio  of  modified  methods  to  base)  (ref.  App.  A,  (k)) 
This  indicator  can  be  used  to  monitor  changes  to  design  throughout  a  project, 
which  can  serve  as  a  leading  indictor  of  delays,  cost  increases  and  rework.  The 
churn  ratio  is  provided  as  an  indicator  of  the  amount  of  rework  being  accomplished 

for  a  given  attribute.  _ _ 

A  line  chart  combined  with  a  bar  chart  (Figure  3.1-9)  is  used  to  present  the  volatil¬ 
ity  information.  The  information  presented  includes  the  cumulative  number  of 
attributes.  This  is  augmented  by  a  bar  chart  indication  of  the  CRP  number  of  modi- 


Performance 

Analysis 
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fied,  added  and  deleted  attributes. _ 

A  high  level  of  attribute  volatility  may  require  adjustment  to  current  resource  allo¬ 
cations,  effort  estimates,  budgets,  and  schedule.  The  churn  ratio  should  be  consis¬ 
tent  with  the  system  phase.  (Sometimes  it  is  a  measure  of  rework,  other  times 
expected  work.)  In  addition,  adding  and  deleting  of  attributes  late  in  a  project 


could  indicate  an  unstable  design  process. 
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Figure  3.1-9.  Added,  deleted  and  modified  attributes. 
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3.2  Product  Quality 

The  numbers  circled  in  black  in  Table  3.2-1  are  one-to-one  traceable  to  the  justification  for  the  metric 
described  in  Section  2.2  Selection  and  Justification  of  00  unique  Metrics.  Table  3.2-1  identifies  the 
metrics  selected  for  Product  Quality. 


Table  3.2-1.  Product  Quality  Metrics 


ISSUE 

CATEGORY 

RECOMMENDED  METRiCS 

Product 

Quality 

Inheritance 

Number  of  Children  per  Class 

Depth  of  Inheritance  Tree  per  Class 

Object  Structure 

Weighted  Methods  per  Class 

Type  of  Methods  in  Class 

^  Coupling 

Coupling  Between  Classes 

Response  for  a  Class 

3.2.1  Inheritance 

Inheritance  measures  the  structure  of  software  components,  based  on  the  number  of  children.  Com¬ 
plex  components  are  generally  harder  to  test,  are  more  difficult  to  maintain,  and  may  contain  more 
defects  than  less  complex  components.  Inheritance  measures  may  provide  indications  of  the  need  to 
redesign.  In  addition,  inheritance  metrics  can  be  used  to  ascertain  the  effects  of  change  to  a  given 
component.  A  seemingly  small  change  to  a  parent  can  affect  all  of  the  children  and  grandchildren 
adversely.  Determining  the  inheritance  for  a  class  can  help  establish  how  widespread  changes  to  a 
parent  class  actually  are. 
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Number  of  Classes 


3.2.1. 1  Number  of  Children  per  Class 


Product  Quality 

Inheritance 

Count  the  number  of  children  for  each  class 

Sum  the  number  of  classes  having  the  same  number  of  children 

The  number  of  children  per  class  measures  the  number  of  immediate  subclasses 
subordinated  to  a  class  in  the  class  hierarchy.  This  is  a  measure  of  the  horizontal 
breadth  of  the  class  structure.  Threshold:  80%  of  the  classes  in  the  system  should 
have  7  or  more  inherited  subclasses. 

A  histogram  (Figure  3.2-1)  is  used  to  present  the  structure  information.  The  infor¬ 
mation  presented  includes  the  number  of  classes  containing  a  particular  number  of 
children  classes. 

o 

The  percentage  of  children  inherited  should  be  high.  The  greater  the  number  of 
children,  the  greater  the  reuse,  since  inheritance  is  a  form  of  reuse.  There  is  no 
lower  threshold  for  this  metric. 

oTfiR  432  1  0  Median  Mode  Averaqe 

Count  150  100  80  50  30  20  0  0  0  0  8 

Number  of  Children  per  Class 


9876543210 

Number  of  Children 


Figure  3.2-1.  Number  of  children  per  class. 
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3.2.1 .2  Depth  of  Inheritance  Tree  (PIT)  per  Class 

Product  Quality _ 


Inheritance 


Category 

Measure 

Description 


Example 

Graph 

Performance 

Analysis 


Count  the  number  of  nodes  from  each  class  to  the  root  of  the  inheritance  tree 
Sum  the  number  of  classes  containing  the  same  number  of  nodes  between  it  and  the 
root  of  the  inheritance  tree _ 

In  cases  involving  multiple  inheritance,  the  DIT  will  be  the  maximum  length  from 
the  node  to  the  root  of  the  tree.  This  is  a  measure  of  the  vertical  depth  of  the  class 
structure.  Threshold:  80%  of  the  classes  in  the  system  should  have  less  than  6 

inheritance  levels.  _ _ _ 

A  histogram  (Figure  3.2-2)  is  used  to  present  the  structure  information.  The  infor¬ 
mation  presented  includes  the  number  of  classes  with  a  particular  class  tree  depth. 

Large  numbers  of  nesting  levels  in  a  class  structure  is  an  indication  that  too  many 
classes  have  been  created  in  the  system.  The  deeper  a  class  is  in  the  hierarchy,  the 
greater  the  number  of  methods  it  is  likely  to  inherit,  making  it  more  difficult  to 
predict  its  behavior.  A  nesting  level  of  less  than  6  should  be  maintained  throughout 

the  system. _ _ _ _ _ 

234  567  89  Median  Mode  Average 

1  75  50  40  30  20  10  0  0  2  0  2.19 

Depth  of  Inheritance  Tree  per  Class 


Threshold  value:  80% 
of  classes  <  6 


3.2.2  Object  Structure 

The  structure  of  software  is  measured  using  object  structure  measures.  Complex  objects  are  generally 
harder  to  test,  are  more  difficult  to  maintain,  and  may  contain  more  defects  than  less  complex  objects. 
Object  structure  measures  provide  indications  of  the  need  to  redesign  and  of  the  relative  amount  of 
testing  required. 
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3.2.2.1  Weighted  Methods  per  Class 


Issue 

Product  Quality 

Category 

Object  Structure 

Measure 

Identify  the  complexity  of  each  method  (by  using  a  static  code  analyzer  tool) 
[MCCABE] 

For  each  class  sum  the  complexity  for  eaeh  method  in  the  elass  into  a  class 
complexity 

Sum  the  number  of  classes  containing  equivalent  levels  of  class  complexity 

Description 

This  measure  describes  the  complexity  of  a  class  through  the  complexity  of  its 
methods.  Threshold:  elass  complexity  should  not  exceed  70. 

Example 

Graph 

A  histogram  (Figure  3.2-3)  is  used  to  present  the  structure  information.  The  infor¬ 
mation  presented  includes  the  number  of  classes  having  a  particular  class 
complexity. 

Performance 

Analysis 

A  more  complex  class  is  more  difficult  to  maintain.  There  are  reasons,  however,  to 
have  classes  that  have  a  higher  degree  of  complexity.  Overall,  however,  the 
majority  of  the  system  should  not  be  made  up  of  highly  complex  classes.  Classes 
that  exhibit  a  cumulative  complexity  of  70  or  over  should  be  examined  to  ensure 
that  their  complexity  is  Justified.  When  this  occurs  it  is  an  indication  that  all  the 
classes  should  be  reviewed  to  ensure  that  only  those  classes  required  to  be  highly 
complex  are. 

0-9  10-19  20-29  30-39  40-49  50-59  60-69  70-79  80-89  >90  Median  Mode  Average 

Count  100  75  75  50  40  30  20  10  0  0  20  0  21.88 


Weighted  Methods  per  Class 


Class  Complexity 


Figure  3.2-3,  Weighted  methods  per  class. 
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3.2.2.2  Type  of  Methods  in  Class 


Issue 

Product  Quality 

Category 

Object  Structure 

Measure 

Number  of  CRP  classes 

Number  of  CRP  methods  per  class 

Number  of  CRP  private  methods  per  class 

Number  of  CRP  protected  methods  per  class 

Number  of  CRP  public  methods  per  class 

Calculate  cumulative  number  or  private  methods  per  class  (ref.  App.  A,  (1)) 

Calculate  cumulative  number  of  protected  methods  per  class  (ref.  App.  A,  (1)) 
Calculate  cumulative  number  of  public  methods  per  class  (ref.  App.  A,  (1)) 

Description 

The  number  of  public  methods  in  a  class  is  a  measure  of  the  amount  of  system 
functionality  being  provided  by  the  class.  In  addition,  the  number  of  public  meth¬ 
ods  is  a  reflection  of  the  total  number  of  methods  provided  by  the  class,  because 
each  public  method  is  supported  by  some  number  of  private  methods.  Threshold 
value:  Non-public  methods  should  not  exceed  80%  of  design. 

Example 

Graph 

A  100%  stacked  column  (Figure  3.2-4)  is  used  to  present  the  method  type  informa¬ 
tion.  The  information  presented  compares  the  percentage  of  each  method  type  that 
contributes  to  the  total  across  the  method  types. 

Performance 

Analysis 

The  comparison  of  public  to  non-public  methods  in  a  class  is  an  indication  of  the 
amount  of  work  being  performed  by  the  class.  As  a  goal  at  least  20%  of  all  meth¬ 
ods  should  be  public.  In  addition,  classes  with  large  percentages  of  public  methods 
should  be  examined  to  determine  if  some  of  those  should  be  made  private  or 

protected. 

week  1 

week  2 
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Type  of  Methods  in  Class 

fTh  res  hold  value: 


week  week  week  week  week  week  week  week  week  week  week  week 

1  2  3  4  5  6  7  8  9  10  11  12 

Time 


Figure  3.2-4.  Type  of  methods  class. 
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3.2.3  Coupling 

Coupling  measures  the  degree  to  which  the  classes  of  the  system  interchange  information.  There  are 
two  measures  of  coupling.  The  first  is  the  amount  of  data  that  is  passed  between  the  classes.  The 
second  is  the  number  of  responses  possible  for  any  given  method  invocation.  A  system  with  a  high 
degree  of  coupling  can  be  difficult  to  maintain. 
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3.2.3.1  Coupling  Between  Classes 


Product  Quality 


Coupling 


Issue 

Category 


Measure 

Description 

Example 

Graph 

Performance 

Analysis 


Count  the  number  of  methods  called  per  class 

Sum  the  number  of  classes  calling  a  particular  number  of  methods 

This  metric  provides  a  profile  of  the  number  of  other  classes  with  which  a  particu¬ 
lar  class  communicates  (i.e.,.,  counts  the  number  of  external  methods  called  by  a 

particular  class). _ _ _ 

A  histogram  (Figure  3.2-5)  is  used  to  present  the  structure  information.  The  infor¬ 
mation  presented  includes  the  number  of  classes  that  call  a  particular  number  of 
methods. 

Excessive  coupling  between  object  classes  is  detrimental  to  modular  design  and 
prevents  reuse.  The  more  independent  a  class  is,  the  easier  it  is  to  reuse  in  another 
application.  In  order  to  improve  modularity  and  promote  encapsulation,  class  cou¬ 
pling  should  be  kept  to  a  minimum.  The  larger  the  number  of  couples,  the  higher 
the  sensitivity  to  changes  in  other  parts  of  the  design.  A  measure  of  coupling  is 
useful  to  determine  how  complex  the  testing  of  various  parts  of  the  design  is  likely 
to  be.  The  higher  the  class  coupling,  the  more  rigorous  the  testing  needs  to  be.  No 
threshold  has  been  defined  for  this  metric, _ 


10-14  15-19  20-24  25-29  30-34  35-39  40-44  >45  Median  Mode  Average 

80  50  35  30  20  15  10  5  3  0  10.65 

Coupling  Between  Classes 


-14  15-19  20-24  25-29  30-34  35-39  40-44 

Number  of  Methods  Called  per  Class 


Figure  3.2-5.  Coupling  between  classes. 


3.2.3.2  Response  for  a  Class(RFC) 


Product  Quality 

Coupling 

Number  of  methods  in  other  classes  that  can  respond  to  any  message  sent  by  the 
class  under  consideration 

Number  of  classes  that  respond  to  the  messages 

The  response  set  of  a  class  is  a  count  of  methods  accessible  to  an  object  of  this 
class  type  due  to  inheritance. 

A  histogram  (Figure  3.2-6)  is  used  to  present  the  structure  information.  The  infor¬ 
mation  presented  includes  the  number  of  classes  having  a  particular  number  of 
methods  in  its  response  set. 

This  metric  measures  the  degree  of  class  coupling.  A  low  level  of  coupling  is  nec¬ 
essary  to  reduce  system  complexity.  Therefore,  the  optimal  RFC  metric  would  be 
to  have  the  largest  number  of  classes  contained  in  the  lower  response  categories. 

No  thresholds  have  been  provided  for  this  metric. _ 

0  1  234  567  89  Median  Mode  Average 

Count  50  100  75  65  50  30  20  10  0  0  2  0  2.19 


Response  for  a  Class 


Figure  3.2-6.  Response  for  a  class. 
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3.3  Schedule  and  Progress 

The  numbers  circled  in  black  in  Table  3.3-1  are  one-to-one  traceable  to  the  justification  for  the  metric 
described  in  Section  2.2,  Selection  and  Justification  of  00  unique  Metrics.  Table  3.3-1  identifies  the 
metrics  selected  for  Schedule  and  Progress.  The  metrics  included  in  the  Schedule  and  Progress  sec¬ 
tion  must  be  linked  to  the  Integrated  Master  Plan  (IMP)  and  Integrated  Master  Schedule  (IMS)  to  be 
useful  in  managing  the  00  development.  [IMP/IMS]  The  prudent  project  manager  of  an  00  devel¬ 
opment  effort  must  ensure  that  the  appropriate  terminology  is  reflected  in  these  program-level  docu¬ 
ments.  In  addition,  the  management  system  used  to  track  the  00  development,  generically  referred 
to  as  the  Earned  Value  Management  System  (EVMS),  must  also  reflect  the  terminology  of  the  00 
development. 


Table  3.3-1 .  Schedule  and  Progress  Metrics. 


ISSUE 

CATEGORY 

RECOMMENDED  METRICS 

Schedule 

and 

Milestone 

Plan  vs  Actual  Milestone  Days 

Milestone  Slip  Ratio 

Progress 

Class  Status 

Plan  vs  Actual  Classes  Completed 

Plan  vs  Actual  Methods  Completed 

Plan  vs  Actual  Attributes  Completed 

Class  Traceability  Status 

Integration  Test  Traceability  Status 

Plan  vs  Actual  Classes  that  have  Successfully  Passed  Integration  Test 

^^Use  Case  Status 

Plan  vs  Actual  Use  Cases  Completed 

Use  Case  Traceability  Status 

Functional  Test  Traceability  Status 

Plan  vs  Actual  Use  Cases  that  have  Successfully  Passed  Functional  Test 

Build  Content  - 
Classes 

Plan  vs  Actual  Classes  in  Build 

Ratio  of  Classes  in  Build 

Build  Content  > 

Use  Cases 

Plan  vs  Actual  Use  Cases  in  Build 

Ratio  of  Use  Cases  in  Build 

3.3.1  Milestone 

The  milestone  performance  measure  provides  basic  schedule  and  progress  information  for  key  soft¬ 
ware  development  activities  and  events.  The  measures  also  help  to  identify  and  assess  dependencies 
among  software  development  activities  and  events.  Monitoring  changes  in  schedule  allows  the  proj¬ 
ect  manager  to  assess  the  risk  in  achieving  future  milestones.  Milestone  metrics  are  not  unique  to 
object-oriented  development.  However,  when  the  OO-specific  life-cycle  model  (described  in  Appen¬ 
dix  C)  is  used,  different  milestones  are  defined  with  different  names  than  the  traditional  milestones 
used  in  non-OO  developments.  (An  example  of  an  OO-specific  life-cycle  model  would  be  that  which 
is  described  in  the  Rational  Unified  Process  (RUP).  [RATIONAL])  The  metrics  described  in  this 
section  have  been  adapted  to  use  the  OO-specific  milestones.  Some  object-oriented  implementations 
may,  however,  use  the  traditional  milestone  terminology,  in  which  case  the  traditional  milestone  met¬ 
rics  would  be  used  instead. 
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Plan  Date 
Plan  Days 
Actual  Date 
Actual  Days 
Late  Start 
Total  Variance 
Cum  Variance 


01/01/2000  05/31/2000  11/30/2000  05/31/2001  10/31/2001  05/31/2002  05/31/2003  05/31/2004 

150  180  180  150  210  360  360 

01/15/2000  06/15/2000  12/31/2000  07/15/2001  01/02/2002  07/31/2002  10/31/2003  06/30/2004 
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195 
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209 
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240 
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60 
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30 

14 
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46 

60 

79 

59 

240 

-90 

14 

29 

75 

135 

214 

273 

513 

423 

Plan  vs.  Actual  Milestone  Days 


fa  300 


I  Plan  Days 
I  Actual  Days 
•Cum  Variance 


ATP  LCO  LCA  IOC  IOC2  IOC3  IOC4  FOC 
Milestones 


ATP  =  Authority  to  Proceed,  LCO  =  Life  Cycle  Objectives,  LCA  =  Life  Cycle  Architecture,  IOC  =  Initial  Operational  Capability,  FOC  =  Rnal  Operational  Capability 

Figure  3.3-1.  Plan  vs.  actual  milestone  days. 


Issue 

Schedule  and  Progress 

Category 

Milestone 

Measure 

Planned  milestone  completion  date. 

Actual  milestone  completion  date 

Number  of  days  between  milestones  (if  this  is  the  first  milestone  then  this  calcula¬ 
tion  is  not  applicable) 

Calculate  milestone  slip  ratio,  which  is  the  ratio  of  the  milestone  variance  to  the 
olanned  days  between  milestones  (ref.  App.  A,  (n)) 

Description 

This  indicator  helps  identify  the  current  status  of  the  project.  It  provides  visibility 
into  the  magnitude  of  the  schedule  slip  when  compared  to  the  overall  length  of  the 
schedule  for  each  milestone 

Example 

Graph 

A  line  chart  (Figure  3.3-2)  is  used  to  present  the  milestone  slip  information.  The 
information  presented  includes  a  milestone  slip  value. 

Performance 

Analysis 

A  ratio  of  zero  is  ideal,  the  larger  the  ratio,  the  worse  the  slip  in  proportion  to  the 
schedule, 

-  ‘  .  _  -  _ 

Plan  Date 
Plan  Days 
Actual  Date 
Actual  Days 
Late  Start 
Variance 
Slip  Ratio 


ATP  LCO  LCA 

01/01/2000  05/31/2000  11/30/2000  05/31/2001  10/31/2001  05/31/2002  05/31/2003  05/3J/2004 
10 

01/15/2000 


•)50  180  180  150  210  360  360 

06/15/2000  12/31/2000  07/15/2001  01/02/2002  07/31/2002  10/31/2003  06/30/2004 
150  196  195  167  209  450  240 

15  30  45  62  60  150  30 

15  46  60  79  59  240  -90 

0  10  0.26  0.33  0-53  0.28  0.67  -0.25 


■Slip  Ratio 


Figure  3.3-2.  Milestone  slip  ratio. 
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3.3.2  Class  Status 

Class  status  measures  address  progress  based  on  the  completion  of  work  units  that  combine  incre¬ 
mentally  to  form  a  complete  software  activity  or  product.  If  objective  completion  criteria  are  defined, 
class  status  measures  are  extremely  effective  for  assessing  progress  at  any  point  in  the  project. 
Objective  completion  criteria  are  defined  as  “measurable  and  useful  indicators  that  demonstrate  that 
the  achievement  or  maturity/progress  in  an  activity  or  accomplishment  has  been  achieved.  Accom¬ 
plishment  criteria  include,  but  are  not  limited  to,  (1)  completed  work  efforts;  (2)  activities  to  confirm 
success  of  meeting  technical,  schedule,  or  cost  parameters;  (3)  Internal  documents  that  provide  results 
of  incremental  verification,  and  (4)  Completion  of  critical  process  activities  and  products.” 

[IMP/IMS]  These  measures  are  used  for  projecting  completion  dates  for  the  activity  or  product. 
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3.3.2.1  Plan  versus  Actual  Classes  Completed 


Issue 

Schedule  and  Progress 

Category 

Class  Status 

Measure 

Refer  to  Section  3. 1.1. 2  (Issue:  Growth  and  Stability,  Attribute:  Size). 
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3.3.2.2  Plan  versus  Actual  Methods  Completed 


Issue 

Schedule  and  Progress 

Category 

Class  Status 

Measure 

Planned  number  of  methods  to  be  completed  during  the  CRP 

Actual  number  of  methods  completed  (i.e.,  coded  and  unit  tested)  during  the  CRP 
Calculate  cumulative  number  of  methods  planned  to  be  completed  (ref.  App.  A, 

(h)) 

Calculate  cumulative  number  of  methods  actually  completed  (ref.  App.  A,  (h)) 

Description 

This  indicator  provides  an  estimate  of  class  status.  Unplanned  additions  and 
changes  to  the  number  and  magnitude  of  methods  can  adversely  influence  sched¬ 
ules  and  costs.  This  metric  can  be  used  to  determine  when  the  implementation 
phase  is  completed. 

Example 

Graph 

A  line  chart  combined  with  a  bar  chart  (Figure  3.3-3)  is  used  to  present  the  class 
status  information.  The  information  presented  includes  the  planned  number  of 
methods  and  the  actual  number  of  methods  plotted  over  time.  A  cumulative  value  is 
included  in  the  line  chart  and  a  CRP  plan/actual  is  provided  in  the  bar  charts. 

Performance 

Analysis 

The  planned  magnitude  of  the  job  must  be  realistic  over  the  period  of  performance. 
Large  changes  in  the  rate  per  period  should  be  evaluated  for  feasibility. 
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week  week  week  week  week  week  week  week  week  week  week  week 
1  2  3  4  5  6  7  8  9  10  11  12 

Time 


Figure  3.3-3.  Plan  versus  actual  methods  completed. 
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3.3.2.3  Plan  versus  Actual  Attributes  Completed 

Schedule  and  Progress _ 


Issue 

Category 


Class  Status 


Planned  number  of  attributes  to  be  completed  during  the  CRP 
Actual  number  of  attributes  completed  (i.e.,  coded  and  unit  tested)  during  the  CRP 
Calculate  cumulative  number  of  attributes  planned  to  be  completed  (ref.  App.  A, 
0)) 

Calculate  cumulative  number  of  attributes  actually  completed  (ref.  App.  A,  (i)) 
This  indicator  provides  an  estimate  of  the  programming  associated  with  the  devel¬ 
opment  of  data  structures  within  the  class.  Unplanned  additions  and  changes  to  the 
number  and  magnitude  of  attributes  can  adversely  influence  schedules  and  costs. 


3.3.2.4  Class  Traceability  Status 


Issue 

Category 

Measure 


Description 


Example 

Graph 

Performance 

Analysis 


#  SW  Classes 
Traced  to  Use  Case 
Derived  Class 
Not  Traced  (TBD) 

Cum  SW  Classes 
Cum  SW  Class  T raced 


Schedule  and  Progress  _ 


Class  Status 

Number  of  classes  per  CRP 

Number  of  classes  traced  to  use  cases  per  CRP 

Number  of  derived  classes  per  CRP 

Number  of  classes  not  yet  traced  to  use  cases  per  CRP 

Calculate  cumulative  number  of  classes  defined  (ref.  App.  A,  (p)) 

Calculate  cumulative  number  of  classes  traced  to  use  cases  or  derived  (ref,  App.  A, 

(P))  _ 

The  class  traceability  status  metric  measures  the  degree  to  which  software  design 
products  have  implemented  the  software  requirements. 


A  line  chart  combined  with  a  bar  chart  (Figure  3.3-5)  is  used  to  present  the  trace- 
ability  information.  The  information  presented  includes  a  cumulative  traceability 
status.  This  is  augmented  by  a  bar  chart  indication  of  the  CRP  use  case  traceability 
status. _ 

Traceability  can  be  a  valuable  management  support  tool  at  system  requirements, 
design  or  other  joint  reviews.  It  may  also  indicate  those  areas  of  software  require¬ 
ments  or  design  which  have  not  been  properly  defined.  Persistent  numbers  of 
untraced  classes  can  indicate  problems  in  the  requirements  (use  cases),  design 

(classes)  or  both. _ 

week  1  week  2  week  3  week  4  week  5  week  6  week  7  week  8  week  9  week  10  week  1 1  week  12 


Figure  3.3-5.  Class  traceability  status. 
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3.3.2.5  Integration  Test  Traceability  Status 


Schedule  and  Progress _ 


Class  Status 


Issue 

Category 


Measure 


Description 


Example 

Graph 

Performance 

Analysis 


Number  of  classes  per  CRP 

Number  of  classes  traced  to  test  cases  per  CRP 

Number  of  classes  not  yet  traced  to  a  test  case  per  CRP 

Calculate  cumulative  number  of  classes  defined  (ref.  App.  A,  (q)) 

Calculate  cumulative  number  of  classes  traced  to  test  cases  (ref.  App.  A,  (q)) _ 


The  integration  test  traceability  status  metric  measures  the  degree  to  which  the 
integration  test  cases  cover  the  software  design.  The  integration  testing  is  focused 
on  the  structure  of  the  system  and  primarily  focuses  on  interface  testing.  Having 


traceability  at  this  level  ensures  that  appropriate  structural  coverage  has  been 


achieved  in  the  testin 


A  line  chart  combined  with  a  bar  chart  (Figure  3.3-6)  is  used  to  present  the  trace 


ability  information.  The  information  presented  includes  a  cumulative  traceability 
status.  This  is  augmented  by  a  bar  chart  indication  of  the  CRP  use  case  traceability 
status 


Traceability  of  classes  to  integration  test  cases  provides  the  capability  to  track 
failed  test  cases  back  to  areas  of  the  software  design.  Persistent  numbers  of  classes 


untraced  to  integration  test  cases  can  indicate  an  inadequate  integration  test  pro 
gram.  This  can  lead  to  defects  remaining  in  the  software  products  until  late  in  the 
rocram  when  it  is  more  time  consuming  and  expensive  to  fix  them 


3.3.2.6  Plan  verses  Actual  Classes  that  have  Successfully  Passed 
Integration  Test  _ 


Issue 

Schedule  and  Progress 

Category 

Class  Status 

Measure 

Planned  number  of  classes  tested  and  passed  per  CRP 

Actual  number  of  classes  tested  and  passed  per  CRP 

Calculate  cumulative  number  of  planned  classes  tested  and  passed  (ref.  App.  A,  (s)) 
Calculate  cumulative  number  of  actual  classes  tested  and  passed  (ref.  App.  A,  (s)) 

Description 

The  Test  Passed  indicator  monitors  test  progress  during  the  integration  and  test 
phase  of  a  software  project.  The  criteria  for  determining  whether  a  class  has  been 
successfully  tested  must  be  well  defined  for  this  metric  to  be  meaningful. 

Example 

Graph 

A  line  chart  combined  with  a  bar  chart  (Figure  3.3-7)  is  used  to  present  the  test 
information.  The  information  presented  includes  the  planned  number  of  successful 
test  cases  and  the  actual  number  of  successful  test  cases  plotted  over  time.  A 
cumulative  value  is  included  in  the  line  chart  and  a  CRP  plan/actual  is  provided  in 
the  bar  chart. 

Performance 

Analysis 

If  the  actual  number  of  classes  successfully  tested  slips  behind  the  number  planned, 
this  can  indicate  problems  in  the  software  integration  test  program  itself  (e.g., 
insufficient  or  inexperienced  staff)  or  could  indicate  problems  with  the  software 
itself  (e.g.  large  numbers  of  defects  identified  by  the  integration  testing). 

VO  vuppkr^  wppk4  wppk  6  week  6  week  7  week  8  week  9  week  10  week  11  week  12 

Plan  35746  10  64731  1 

Actual  1  36378957321 

Cum  Plan  3  8  15  19  25  35  41  45  52  55  56  57 

Cum  Act  1  4  10  13  20  28  37  42  49  52  54  55 

Plan  vs  Actual  Classes  that  have  Successfully  Passed 
Integration  Test 


Time 


Figure  3.3-7.  Plan  verses  actual  classes  that  have  successfully  passed  integration  test. 
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3.3.3  Use  Case  Status 

Use  case  status  measures  address  progress  based  on  the  completion  of  work  units  that  combine 
incrementally  to  form  a  complete  software  activity  or  product.  If  objective  completion  criteria  are 
defined,  use  case  status  measures  are  extremely  effective  for  assessing  progress  at  any  point  in  the 
project.  Objective  completion  criteria  are  defined  as  “measurable  and  useful  indicators  that  demon¬ 
strate  that  the  achievement  or  maturity/progress  in  an  activity  or  accomplishment  has  been 
achieved. .  .Accomplishment  criteria  include,  but  are  not  limited  to:  1)  completed  work  efforts;  2) 
activities  to  confirm  success  of  meeting  technical,  schedule,  or  cost  parameters;  3)  internal  docu¬ 
ments,  which  provide  results  of  incremental  verification;  and  4)  completion  of  critical  process  activi¬ 
ties  and  products.”  [IMP/IMS]  They  are  used  for  projecting  completion  dates  for  the  activity  or 
product. 
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3.3.3.1  Plan  versus  Actual  Use  Cases  Completed 


Issue 

Schedule  and  Progress 

Category 

Use  Case  Status 

Measure 

Refer  to  section  3. 1.1.1  (Issue:  Growth  and  Stability,  Category:  Size). 
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3.3.3.2  Use  Case  Traceability  Status 


Issue 

Category 


Schedule  and  Progress 


Use  Case  Status 


Measure 


Description 


Number  of  use  cases  per  CRP 

Number  of  use  cases  traced  to  functional  requirement(s)  per  CRP 
Number  of  derived  use  cases  per  CRP 

Number  of  use  cases  not  yet  traced  to  parent  requirements  per  CRP 
Calculate  cumulative  number  of  use  cases  defined  (ref.  App.  A,  (o)) 

Calculate  cumulative  number  of  use  cases  traced  to  parent  requirement(s)  or 

derived  (ref.  App.  A,  (o))  _ 

The  traceability  metric  measures  the  degree  to  which  software  products  have 
implemented  functional  requirements  allocated  from  higher  level  specifications. 


Example 

Graph 

Performance 

Analysis 


#  SW  Use  Cases 
Traced  to  High  Reqt 
Derived  Use  Cases 
Not  Traced  (TBD) 
Cum  SW  Use  Cases 
Cum  SW  UC  Traced 


A  line  chart  combined  with  a  bar  chart  (Figure  3.3-8)  is  used  to  present  the  trace- 
ability  information.  The  information  presented  includes  a  cumulative  traceability 
status.  This  is  augmented  by  a  bar  chart  indication  of  the  CRP  use  case  traceability 

status. _ _ _ _ _ _ 

Traceability  can  be  a  valuable  management  support  tool  at  system  requirement, 
design  or  other  joint  reviews.  It  may  also  indicate  those  areas  of  software  require¬ 
ments  or  design  which  have  not  been  properly  defined.  Persistent  numbers  of 
untraced  use  cases  can  indicate  problems  in  the  software  requirement  definition 
(e.g.  incompleteness,  “gold  plating'\  and  incorrect  software  requirements). 
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Figure  3.3-8.  Use  case  traceability  status. 


3.3.3.3  Functional  Test  Traceability  Status 


Schedule  and  Progress 


Issue 

Category 


Use  Case  Status 


Measure 


Description 

Example 

Graph 

Performance 

Analysis 


#  SW  Use  Cases 
Traced  to  Test  Case 
Not  Traced  (TBD) 
Cum  SW  Use  Cases 
Cum  SW  UC  Traced 


Number  of  use  cases  per  CRP 
Number  of  use  cases  traced  to  test  cases  per  CRP 
Number  of  use  cases  not  yet  traced  to  a  test  case  per  CRP 
Calculate  cumulative  number  of  use  cases  defined  (ref  App.  A,  (r)) 

Calculate  cumulative  number  of  use  cases  traced  to  test  cases  (ref  App.  A,  (r)) 

The  traceability  metric  measures  the  degree  to  which  the  functional  test  cases  cover 
the  software  use  cases. 

A  line  chart  combined  with  a  bar  chart  (Figure  3.3-9)  is  used  to  present  the  trace- 
ability  information.  The  information  presented  includes  a  cumulative  traceability 
status.  This  is  augmented  by  a  bar  chart  indication  of  the  CRP  use  case  traceability 

status.  _ 

Traceability  of  use  cases  to  functional  test  cases  provides  the  capability  to  track 
failed  functional  test  cases  back  to  the  software  requirements  as  defined  by  the  use 
cases.  The  failed  tests  can  thus  be  tracked  back  to  specific  mission  needs.  Persis¬ 
tent  numbers  of  use  cases  untraced  can  indicate  an  inadequate  software  qualifica¬ 
tion  test  program.  This  can  lead  to  defects  remaining  in  the  software  product  until 
later  in  the  program  when  it  is  more  time  consuming  and  expensive  to  fix  them. 
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Figure  3.3-9.  Functional  test  traceability  status. 


3.3.3.4  Plan  versus  Actual  Use  Cases  that  have  Successfully  Passed 
Functional  Test  _ 


Schedule  and  Progress  _ 


Use  Case  Status 


Issue 

Category 


Measure 


Description 

Example 

Graph 

Performance 

Analysis 


Plan 
Actual 
Cum  Plan 
Cum  Act 


Planned  number  of  use  cases  tested  and  passed  per  CRP 
Actual  number  of  use  cases  tested  and  passed  per  CRP 

Calculate  cumulative  number  of  planned  software  use  cases  tested  and  passed  (ref. 
App.  A,  (t)) 

Calculate  cumulative  number  of  actual  software  use  cases  tested  and  passed  (ref. 

App.  A,  (t)) _ _ _ _ _ 

The  Test  Passed  indicator  monitors  test  progress  during  the  qualification  phase  of  a 
software  project.  The  criteria  for  determining  whether  a  use  case  has  been  success- 
fullv  tested  must  be  well  defined  for  this  metric  to  be  meaningful. _ 


A  line  chart  combined  with  a  bar  chart  (Figure  3.3-10)  is  used  to  present  the  test 
information.  The  information  presented  includes  the  planned  number  of  test  cases 
and  the  actual  number  of  test  cases  plotted  over  time.  A  cumulate  value  is  included 
in  the  line  chart  and  a  CRP  plan/actual  is  provided  in  the  par  chart. _ 


If  the  actual  number  of  use  cases  successfully  tested  slips  behind  the  number 
planned,  this  can  indicate  problems  in  the  software  qualification  test  program  itself 
(e.g.  insufficient  or  inexperienced  staff)  or  could  indicate  problems  with  the  soft- 
itself  (e.g.  large  numbers  of  defects  identified  by  the  functional  testing). _ 
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Figure  3.3-10.  Plan  verses  actual  use  cases  that  have  successfully  passed  functional  test. 


3.3.4  Build  Content  -  Classes 

These  incremental  capability  measures  count  the  classes  associated  with  each  incremental  delivery. 
An  incremental  delivery  may  be  a  product  shipped  to  a  customer,  or  it  may  be  an  internal  build  deliv¬ 
ered  to  the  next  phase  of  development.  These  measures  are  used  to  determine  whether  capability  is 
being  developed  as  scheduled  or  being  delayed  to  future  deliveries. 
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3.3.4.2  Ratio  of  Classes  in  Build 


Issue 

Schedule  and  Progress 

Category 

Build  Content  -  Classes 

Measure 

Planned  number  of  classes  in  current  build(s)  per  CRP 

Actual  number  of  classes  in  current  build(s)  per  CRP 

Calculate  class  integration  slip  ratio  (ref.  App.  A,  (v)) 

Description 

This  indicator  helps  identify  the  current  status  of  the  build  by  indicating  whether 
fewer  or  more  classes  are  implemented  in  the  build  than  planned.  Threshold  Upper 
Bound  +10%  of  plan. 

Threshold  Lower  Bound  -10%  of  plan. 

Example 

Graph 

A  line  chart  (Figure  3.3-12)  is  used  to  present  the  class  integration  slip  information. 
The  information  presented  includes  a  cumulative  class  integration  slip  value. 

Performance 

Analysis 

Slips  in  activities  are  of  greatest  concern  due  to  the  ripple  effect  in  later  parts  of  the 
schedule.  This  graph  provides  an  overall  assessment  of  the  build.  It  is  useful  for 
ensuring  that  the  project  manager  does  not  lose  sight  of  the  magnitude  of  the  over¬ 
all  schedule  slippage.  The  ideal  class  integration  slip  ratio  is  1.0  (plan  =  actual). 
Fewer  classes  implemented  in  the  build  than  planned  can  indicate  slippage  of 
classes  to  later  builds,  with  associated  cost  and  schedule  impacts.  More  classes 
implemented  in  the  build  than  planned  can  indicate  software  design  instability  or 
uncontrolled  addition  of  design  features  and  capabilities. 
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Figure  3.3-12.  Ratio  of  classes  in  build. 


3.3.5  Build  Content  -  Use  Cases 

These  incremental  capability  measures  count  the  use  cases  associated  with  each  incremental  delivery. 
An  incremental  delivery  may  be  a  product  shipped  to  a  customer  or  it  may  be  an  internal  build  deliv¬ 
ered  to  the  next  phase  of  development.  These  measures  are  used  to  determine  whether  capability  is 
being  developed  as  scheduled  or  being  delayed  to  future  deliveries. 


54 


3.3.5.1  Plan  verses  Actual  Use  Cases  in  Build 


Issue 

Schedule  and  Progress 

Category 

Build  Content  -  Use  Cases 

Measure 

Planned  number  of  Use  Cases  in  current  build(s)  per  CRP 

Actual  number  of  Use  Cases  in  current  build(s)  per  CRP 

Cumulative  number  of  planned  Use  Cases  in  each  build. 

Cumulative  number  of  actual  Use  Cases  in  each  build. 

Description 

When  multiple  builds  or  releases  are  planned,  this  indicator  helps  determine  if  a 
realistic  build  schedule  has  been  established  and  if  progress  in  implementing  the 
software  that  performs  the  use  cases  is  tracking  to  the  plan. 

Example 

Graph 

A  line  chart  (Figure  3.3-13)  is  used  to  present  the  build  information.  The  informa¬ 
tion  presented  includes  cumulative  use  cases  integrated  into  build  status. 

Performance 

Analysis 

Deferments  of  the  use  cases  to  later  builds  without  adjustments  to  the  schedule  are 
of  greatest  concern.  A  5%  or  greater  variance  in  a  single  build,  or  a  10%  variance 
across  two  or  more  builds  should  be  considered  significant.  During  replans,  this 
metric  can  assist  in  analyzing  the  updated  build  plans  for  feasibility  based  on  past 
history. 

3.3.5.2  Ratio  of  Use  Cases  in  Build 

Schedule  and  Progress 


Issue 

Category 


Measure 

Description 

Example 

Graph 

Performance 

Analysis 


Build  Plan 
Build  Act 
Integ  Ratio 
Upper  Bound 
Lower  Bound 


Build  Content  -  Use  Cases 

Planned  number  of  use  cases  in  current  build(s)  per  CRP 
Actual  number  of  use  cases  in  current  build(s)  per  CRP 

Calculate  use  case  integration  slip  ratio  (ref.  App.  A,  (u)) _ 

This  indicator  helps  identify  the  current  status  of  the  build  by  indicating  whether 
fewer  or  more  use  cases  are  implemented  in  the  build  than  planned.  Threshold 

er  bound  +10%  of  plan.  Threshold  lower  bound  -10%  of  plan. _ 

A  line  chart  (figure  3.3-14)  is  used  to  present  the  use  case  integration  slip  informa¬ 
tion.  The  information  presented  includes  a  cumulative  use  case  integration  slip 
value. 

Slips  in  activities  are  of  greatest  concern,  due  to  the  ripple  effect  in  later  parts  of 
the  schedule.  This  graph  provides  an  overall  assessment  of  the  build.  It  is  useful 
for  ensuring  that  the  project  manager  does  not  lose  sight  of  the  magnitude  of  the 
overall  schedule  slippage.  The  ideal  use  case  integration  slip  ratio  is  1.0  (plan  = 
actual).  Fewer  use  cases  implemented  in  the  build  than  planned  can  indicate  slip¬ 
page  of  use  cases  to  later  builds,  with  associated  cost  and  schedule  impacts.  More 
implemented  in  the  build  than  planned  can  indicate  software  require- 

_ ments  instability  or  uncontrolled  software  requirements  growth. _ 
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Figure  3.3-14.  Ratio  of  use  cases  in  build. 


4.  00  Technology  Transition  and  Metrics  Selection 


Metrics  selection  for  a  program  is  difficult.  Selecting  metrics  for  use  on  an  OO  development  program 
is  especially  challenging  since  00  techniques  are  currently  in  an  industry-wide  transition.  The  fol¬ 
lowing  guidance  on  metrics  selection  is  provided  to  augment  metrics  selection  information  provided 
in  more  general  materials  such  as  Practical  Software  Measurement.  [PSM]  Specifically,  this  portion 
of  the  report  addresses  the  unique  problems  associated  with  technology  transitions  and  provides  guid¬ 
ance  on  how  to  address  metrics  selection  for  an  OO  technology  transition. 

How  well  a  developer  uses  OO  technology  depends  on  how  far  along  that  developer  is  on  two  curves. 
The  first  is  the  technology  transition  life-cycle  curve,  and  the  second  is  the  project  culture  curve. 
Before  making  any  specific  OO  metrics  recommendations,  acquisition  personnel  must  assess  where 
the  developer  is  on  these  curves.  That  insight  will  help  acquisition  personnel  understand  why  a 
developer  is  implementing  the  OO  technology  and  OO  metrics  in  a  particular  way  and  what  recom¬ 
mendations  would  be  effective.  The  developers  themselves  also  need  to  understand  their  position 
along  these  two  curves  for  effective  transition  to  the  OO  technology.  The  following  paragraphs 
describe  the  characteristics  of  these  two  curves.  Following  a  description  of  the  two  curves,  guidelines 
are  provided  on  what  metrics  may  be  most  useful  for  any  given  developer’s  location  on  these  curves. 

This  section  of  the  report  is  not  intended  to  provide  overall  guidance  on  metrics  selection,  which  is  a 
much  broader  issue.  The  reader  is  referred  to  Practical  Software  Measures  [PSM]  for  more  informa¬ 
tion  on  the  topic  of  how  to  select  the  full  set  of  metrics  to  be  used  for  a  particular  program. 


4.1  Technology  Transition  Life  cycle 

The  general  model  of  the  technology  transition  life  cycle  is  shown  in  Figure  4.1-1.  This  model  con¬ 
tains  six  phases:  Contact,  Awareness,  Understanding,  Trial  Use,  Limited  Adoption,  and 


TIME 


Adapted  from:  Rogers.  Everett  M,,  Diffusion  of  Innovation. 

Figure  4.1-1.  Technology  transition  life  cycle. 
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Institutionalization.  For  the  purposes  of  this  description,  these  six  phases  will  be  summarized  into 
three  phases:  Awareness,  Exploration,  and  Adoption.  In  the  awareness  phase,  the  organization  is 
becoming  knowledgeable  in  the  technology.  In  the  exploration  phase,  the  organization  is  becoming 
informed  about  how  to  apply  the  technology.  And  finally,  in  the  adoption  phase,  the  organization 
becomes  adept  in  applying  the  technology. 

The  Awareness  Phase  is  characterized  by  a  low  level  of  commitment  (in  terms  of  resources  or  people) 
and  requires  a  long  time  to  reach  the  next  phase.  During  this  phase,  the  organization  is  discovering 
what  the  technology  is,  developing  a  philosophy  for  using  it,  and  beginning  to  understand  what  appli¬ 
cations  it  can  be  applied  to. 

The  Exploration  Phase  is  characterized  by  a  large  increase  in  commitment  over  a  short  period  of  time. 
The  organization  at  this  phase  has  developed  a  use  for  the  identified  technology  within  the  organiza¬ 
tion  and  has  obtained  a  commitment  to  this  idea  from  the  decision-making  structure  of  the  organiza¬ 
tion.  The  decision-making  structure  has  elected  to  utilize  the  technology,  on  a  limited  basis,  to  see 
whether  there  is  merit  to  the  idea.  Being  unprepared  for  the  needed  increased  commitment  in  this 
phase  can  often  be  the  death  of  a  well-meaning  technology  transition  program,  while  being  successful 
during  an  exploration  phase  can  catapult  the  technology  into  the  mainstream  of  the  organization.  This 
phase  is  the  make  or  break  phase.  Few  technologies  that  are  unsuccessful  during  an  exploration  phase 
are  continued  for  further  development. 

The  last  and  final  phase  is  the  Adoption  Phase.  During  this  phase,  the  organization  has  achieved 
some  success  in  applying  the  technology  in  a  limited  sense,  and  the  technology  is  transitioning  to 
being  applied  globally  throughout  the  organization.  At  this  point,  the  technology  will  need  to  be  able 
to  be  adaptable  to  various  applications. 

The  technology  transition  curve  relates  to  the  DoD  Acquisition  life  cycle  in  that  one  would  expect  to 
see  mature  technologies  (adoption  phase)  being  applied  during  the  Production  and  Deployment  phase. 
Less  mature  technologies  (Exploration  Phase)  would  be  developed  during  the  Concept  &  Technology 
Development  phase.  The  System  Development  &  Demonstration  phase  would  be  a  mixture  of  the 
Adoption  and  Exploration  Phase  technologies.  Technologies  that  are  characterized  as  being  in  an 
awareness  phase  would  be  contracted  for  using  the  technology  development  contracts,  which  gener¬ 
ally  occur  before  a  program  enters  the  Acquisition  life  cycle. 

Ideally,  the  software  development  technologies  applied  to  a  product  development  or  system  develop¬ 
ment  and  demonstration  contract  are  all  at  the  adoption  phase  since  this  would  provide  the  least  risk. 
However,  this  is  not  always  possible,  especially  when  multiple  subcontractors  are  performing  on  a 
contract.  In  this  case,  for  a  given  technology,  each  of  the  subcontractors  may  be  at  a  different  place 
on  the  technology  transition  life-cycle  curve. 


4.2  Technology  Adoption  Curve 

The  technology  adoption  curve  characterizes  the  culture  of  the  organization  that  is  attempting  to 
apply  the  new  technology.  While  not  all  individuals  in  an  organization  must  exhibit  a  strong  desire  to 
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adopt  the  new  technology,  a  majority  of  individuals  must  exhibit  a  willingness  to  at  least  accept  the 
new  technology. 

The  technology  adoption  curve  shown  in  Figure  4.2-1  identifies  the  number  of  individuals  that  fall 
into  various  categories  during  a  technology  transition  effort.  This  identification  is  shown  as  a  func¬ 
tion  of  time.  Early  on,  very  few  people  are  involved  and  can  be  described  as  innovators.  Later,  more 
people  become  involved  and  can  be  described  as  early  adopters.  These  people  are  now  ready  to  man¬ 
age  the  transition.  Finally,  the  largest  quantity  of  personnel  (i.e.,  the  majority)  becomes  involved  in 
the  adoption,  but  these  individuals  require  proof  of  the  effectiveness  of  the  new  technology  before 
they  can  be  full  adopters.  Finally,  the  heavy  skeptics  and  laggards  may  become  involved,  but  cannot 
be  counted  on  to  support  the  technology  transition.  A  successful  technology  adoption  would  enlist 
the  first  three  categories  of  individuals  within  an  organization  (i.e.,  innovators,  early  adopters,  and  the 
majority). 


4.3  Relationship  Between  Technology  Transition  Life  cycle 
and  Technology  Adoption  Curve 

The  relationship  of  the  technology  transition  life-cycle  curve  to  the  technology  adoption  bell  curve  is 
as  follows.  The  innovators  lead  the  effort  performed  during  the  awareness  phase.  During  the  Explo¬ 
ration  Phase,  a  case  is  developed  for  why  the  technology  is  useful;  additional  individuals  (i.e.,  the 
early  adopters)  become  involved  in  determining  the  value  of  the  technology  to  the  organization. 
These  people  usually  become  technology  managers.  During  this  phase,  some  of  the  majority  (i.e.,  the 
“need  evidence”)  people  are  becoming  involved,  but  it  is  still  primarily  driven  by  the  innovators  (i.e., 
“fanatics  and  champions”)  and  the  early  adopters  (e.g.,  “technology  managers”).  Finally,  as  the  tech¬ 
nology  is  rolled  out  in  the  organization,  during  the  adoption  phase,  the  majority  of  the  organization 
becomes  involved.  During  this  phase,  the  skeptics  and  laggards  have  no  choice  but  to  become 
involved  because  the  new  technology  has  started  to  resemble  a  steam  roller — adopt  it  or  get  run  over. 


Table  4.3-1  maps  the  major  divisions  of  the  technology  transition  life-cycle  curve  against  the  major 
divisions  of  the  technology  adoption  curve. 


TIME 

Adapted  from:  Moore.  Geoffty  A.,  Crossing  the  Chasm. 

Figure  4.2-1.  Technology  adoption  curve. 
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Table  4.3-1.  Technology  Transition  Life  Cycle  Divisions  versus  Technology  Adoption  Curve  Divisions 


CATEGORY 

Technology  Phase/ 
Staffed  with 

Awareness 

Exploration 

Adoption 

1.  Innovators 

Match 

Match 

Mismatch 

2.  Early  Adopters 

Match 

Match 

Match 

3.  Majority 

Mismatch 

Match 

Match 

4.  Skeptics 

Mismatch 

Mismatch 

Match 

5.  Laggards 

Mismatch 

Mismatch 

Mismatch 

Depending  upon  whether  the  characteristics  of  the  technology  adoption  staff  type  is  suited  to  the 
work  being  performed  in  the  technology  transition  phase,  each  of  the  intersection  cells  in  this  matrix 
has  been  populated  with  either  “match”  or  “mismatch.”  These  two  mappings  identify  when  there  is  a 
match  and  mismatch  between  the  technology  transition  life-cycle  phase  and  the  types  of  people  from 
the  teehnology  adoption  eurve  who  perform  that  aetivity. 

Consider,  for  example,  the  situation  when  any  of  the  teehnology  transition  phases  are  staffed  and  led 
by  a  laggard  who  was  highly  suceessful  on  a  previous  program  and  has  been  selected  for  a  leadership 
position  on  a  newly  won  eontract  that  is  applying  the  latest  technology  currently  being  deployed  in 
the  R&D  labs.  This  individual  is  well  versed  in  the  maintenance  processes  and  has  a  heavy  disposi¬ 
tion  towards  installing  the  latest  configuration  management  tools  to  ensure  proper  software  control. 
However,  the  individual  is  not  well  versed  in  the  technologies  being  applied  on  the  new  contract  or  in 
the  project  management  implications  of  those  technologies.  This  person’s  existing  skills  would  not 
be  applicable  during  the  awareness  or  exploration  phases.  Only  during  the  adoption  phase,  after  the 
technology  has  been  transitioned  and  is  being  successfully  applied,  would  his  skills  be  useful. 


Metrics  can  be  used  to  mitigate  the  risks  of  inadequate  project  management  that  can  occur  when  there 
is  a  mismatch  between  the  technology  adoption  staff  type  and  the  teehnology  transition  life-cycle 
phase.  For  example,  if  there  is  a  laggard  or  an  innovator  performing  the  job  of  teehnology  adoption 
and  they  are  ill  suited  to  perform  the  job,  metrics  can  be  used  to  compensate  for  their  shortcoming. 
For  instance,  a  laggard  often  is  competent  in  project/program  management  and  lacking  in  the  tech¬ 
nology.  For  this  situation,  stressing  the  technology  product  quality  metric  issue  area  will  ensure  that 
the  technology  is  applied  properly.  Similarly,  an  early  adopter  often  is  competent  in  the  technology 
but  lacking  in  project/program  management.  For  this  situation,  stressing  the  schedule  and  prog¬ 
ress/growth  and  stability  metrics  categories  will  ensure  that  the  project/program  management  effort  is 
performed  properly. 


4.4  Selecting  Object-Oriented  Metrics 

The  technology  transition  life-cycle  curve  is  used  to  gauge  what  metrics  would  be  useful  during  the 
application  of  object-oriented  technologies. 
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4.4.1  Technology  Transition  Life  cycle  -  Awareness  Phase 

A  program  that  is  characterized  as  being  in  the  Awareness  Phase  is  one  in  which  the  organization 
adopting  the  technology  has  just  barely  scratched  the  surface  of  the  technology.  The  project  is  proba¬ 
bly  struggling  to  determine  how  the  technology  will  be  used.  The  organization's  technology  aware¬ 
ness  can  be  characterized  as  “one  deep.”  There  is  probably  just  one  person  (or  at  most  a  few)  who 
understands  how  the  technology  will  be  used  and  the  methodology  for  using  it.  In  this  phase,  a  pro¬ 
gram  should: 

•  Define  and  stabilize  a  process  for  using  the  technology 

•  Stabilize  the  product  scope 

•  Have  peer  reviews  of  all  technology  artifacts  with  the  technology  “expert” 

OO  measurement  categories  that  can  help  ensure  that  these  things  are  happening  are  Use  Case  Status 
and  Requirements  Volatility.  Other  metrics  categories  useful  for  this  purpose  include  Staff  Experi¬ 
ence,  Staff  Turnover,  CMM  Level,  and  Review  Status.  These  measurements  are  summarized  in 
Table  4.4-1. 


Table  4.4-1.  Goal  Question  Metric  Applied  to  the  Awareness  Phase 


Goal 

Question 

Category 

Define  and  stabilize 
technology  process 

Is  there  organizational 
experience  in  applying  new 
technology? 

•CMM  Level 

Stabilize  product 
scope 

Are  requirements  activities  on 
track? 

Have  the  requirements  stabilized? 

•  Use  Case  Status 

•  Requirements 
Volatility 

“Expert”  peer  reviews 

Who’s  on  the  project? 

How  frequently  do  personnel 
change? 

Are  the  review  activities  on  track? 

•  Staff  Experience 

•  Staff  Turnover 

•  Review  Status 

4.4.2  Technology  Transition  Life  cycle  -  Exploration  Phase 

A  program  that  is  characterized  as  being  in  the  Exploration  Phase  is  usually  one  in  which  a  number  of 
individuals  have  become  believers  in  the  technology  but  do  not  fully  understand  it.  At  this  step,  most 
of  the  organization  is  in  favor  of  the  new  technology,  but,  in  many  cases,  the  organization  is  using  the 
terminology  of  the  new  technology  to  describe  what  has  been  done  in  the  past.  This  is  similar  to  what 
happened  in  the  mid- 1 980’ s  with  the  development  of  “Ada-tran”  (FORTRAN  constructs  used  in  the 
Ada  programming  language)  software.  In  the  OO  transition,  for  example,  shared  data  items  may  be 
referred  to  as  objects.  In  this  phase,  a  program  should: 


•  Stabilize  the  product  design  as  soon  as  possible 

•  Define  what  quality  criteria  the  OO  artifacts  and  code  will  comply  with 
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•  Monitor  quality  criteria  metrics  regularly  to  ensure  proper  technology  application 

•  Have  peer  reviews  of  all  design  decomposition  artifacts  with  the  technology  “expert” 


OO  measurement  categories  that  can  help  to  ensure  that  these  things  are  happening  include  Inheri¬ 
tance,  Object  Structure,  Coupling,  Class  Status,  and  Size.  Other  measurement  categories  useful  for 
this  purpose  include  Staff  Experience,  Staff  Turnover,  and  Review  Status.  These  measurements  are 
summarized  in  Table  4.4-2. 


Table  4.4-2.  Goal  Question  Metric  Applied  to  the  Exploration  Phase 


Goal 

Question 

Category 

Stabilize  product 
design 

Are  design  activities  on  track? 

•  Class  Status 

•  Design  Volatility 

Define  and  monitor 
OO  artifacts  and 
code  quality  criteria 

Have  quality  criteria  been  defined*) 
Are  quality  criteria  being 
monitored? 

Are  OO  artifacts  and  code  quality 
within  normal  range? 

•  Inheritance 

•  Object  Structure 

•  Coupling 

“Expert”  peer  reviews 

Who’s  on  the  project? 

How  frequently  do  personnel 
change? 

Are  the  review  activities  on  track? 

•  Staff  Experience 
•Staff  Turnover 

•  Review  Status 

4.4.3  Technology  Transition  Life  cycle  -  Adoption  Phase 

A  program  that  is  characterized  as  being  in  the  Adoption  Phase  is  usually  one  in  which  a  cadre  of 
individuals  exist  that  have  actually  used  the  technology  and  know  how  to  apply  it.  In  this  environ¬ 
ment,  the  experienced  individuals  will  not  be  dedicated  to  a  specific  program;  they  have  become  a 
corporate-wide  resource.  The  emphasis  should  be  on  ensuring  that  each  program  becomes  proficient 
in  what  the  experts  know  as  soon  as  possible.  In  this  phase,  a  program  should: 

•  Stabilize  the  product  scope 

•  Stabilize  the  product  design 

•  Define  what  quality  criteria  the  OO  artifacts  and  code  will  comply  with 

•  Monitor  quality  criteria  metrics  regularly  to  ensure  proper  technology  application 

•  Manage  evolutionary  builds 

OO  measurement  categories  that  can  help  to  ensure  that  these  things  are  happening  include  Milestone 
Status,  Build  Content,  Size,  Requirements  Volatility,  Design  Volatility,  Inheritance,  Object  Structure, 
Coupling,  Class  Status,  and  UseCase  Status.  These  measurements  are  summarized  in  Table  4.4-3. 
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Table  4.4-3.  Goal  Question  Metric  Applied  to  the  Adoption  Phase. 


Goal 

Question 

Category 

Stabilize  product 
scope 

Are  requirements  activities  on 
track? 

Have  the  requirements  stabilized? 

•  Use  Case  Status 

•  Requirements 
Volatility 

Stabilize  product 
design 

Are  design  activities  on  track? 

•  Class  Status 
•Design  Volatility 

Define  and  monitor 
00  artifact  and  code 
quality  criteria 

Have  quality  criteria  been  defined? 
Are  quality  criteria  being 
monitored? 

Are  00  artifacts  and  code  quality 
within  normal  range? 

•  Inheritance 

•  Object  Structure 
•Coupling 

Manage  Evolutionary 
Builds 

Is  the  program  on  Track? 

Is  functionality  being  slipped? 

•  Milestone  Status 

•  Build  Content 
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5.  Summary 


The  Object-Oriented  methodology  is  the  latest  in  the  development  philosophies  to  be  transitioned  into 
the  DoD  software  development  community.  This  methodology  is  particularly  compatible  with  the 
evolutionary  software  development  life-cycle  model  currently  being  required  for  use  on  all  DoD  large 
software-intensive  system  acquisitions.  This  life-cycle  management  approach  is  based  on  the  evolu¬ 
tionary  development  philosophy  where  the  software  life  cycle  is  iterated  a  number  of  times  to  develop 
multiple  object-oriented  products  of  increasing  capability.  These  two  components,  the  object- 
oriented  methodology  and  its  associated  evolutionary  life  cycle,  are  referred  to  as  object  technology. 
The  application  of  object  technology  to  the  development  of  software-intensive  systems  provides  some 
unique  management  challenges. 

Measurement  is  a  critical  tool  in  the  quest  for  improved  product  quality  and  decreased  cost  and 
schedule.  In  fact,  effective  management  and  control  of  a  large  software  system  development  effort 
are  not  possible  without  it.  While  many  organizations  use  some  form  of  software  measurement,  most 
do  not  have  mature  measurement  programs.  In  addition,  most  organizations  that  have  made  or  are 
making  a  transition  to  OO  development  have  not  adapted  their  measurement  programs  to  fully 
address  OO  development  products,  processes,  and  resources.  The  guidance  in  this  report  is  meant  for 
organizations  and  projects  that  need  to  adapt  their  existing  measurement  programs  for  OO  develop¬ 
ment.  The  intent  of  this  report  is  to  augment  existing  metrics  information  with  a  primer  on  the  unique 
aspects  of  OO  development  and  how  object  technology  drives  metrics  selection  and  use. 

A  software  development  project  utilizing  Object  technology  has  the  same  software  development 
issues  that  a  conventional  project  would.  For  this  reason,  this  report  is  presented  utilizing  the  format 
of  the  industry-accepted  Practical  Software  Measures.  [PSM]  This  framework  is  then  extended  to 
include  the  OO-unique  issues. 

For  OO  development,metrics  can  be  helpful  not  only  in  providing  information  on  development  status, 
problems,  and  risks,  but  also  in  evaluating  the  effectiveness  of  OO  methods  and  tools  themselves. 
Measurement  can  be  used  to  track  progress  toward  taking  full  advantage  of  the  OO  paradigm.  By 
providing  data  on  OO  structural  attributes,  OO  metrics  can  help  assess  whether  or  not  OO  methods 
are  being  used  as  intended  to  facilitate  modifiability  and  reusability.  Finally,  as  organizations  modify 
their  OO  processes  with  the  intent  of  improvement,  OO  metrics  are  needed  to  assess  whether  or  not 
intended  improvements  are  indeed  realized.  Thirty-one  detailed  metrics  descriptions  specific  to  sys¬ 
tems  being  developed  with  object  technology  are  provided  that  cover  the  issues  of  growth  and  stabil¬ 
ity,  product  quality,  and  schedule  and  progress. 

Initially  a  program  selecting  to  use  object  technologies  may  require  a  technology  transition  phase  in 
order  to  increase  the  understanding  of  developers,  management,  senior  management,  and  customer 
personnel  on  the  methodology  and  its  application  to  the  software  life-cycle  management  techniques. 
Following  this,  a  phase  of  institutionalization  may  be  needed  where  the  technique  becomes  part  of 
normal  operations.  When  these  phases  are  complete,  the  organization  will  be  using  the  object  tech- 


65 


nologies  effectively  and  efficiently  as  part  of  normal  operations.  One  of  the  key  areas  in  which 
management  insight  during  a  technology  transition  can  be  achieved  is  through  the  use  of  appropriate 
software  development  metrics  for  the  OO  paradigm.  This  report  discusses  how  the  technology  tran¬ 
sition  lifecycle  influences  which  types  of  metrics  may  be  considered  useful.  For  a  full  discussion  of 
metrics  selection  reference  the  Practical  Software  Measurement  [PSM]. 

Planning  for  the  use  of  metrics  during  an  acquisition  is  an  important  aspect  of  management  oversight 
for  both  the  acquirer  and  the  developer.  For  the  acquirer,  a  detailed  description  of  what  metrics 
information  is  needed  and  how  to  contractually  transmit  the  information  request  to  the  developer  has 
been  provided  in  Appendix  D. 

For  metrics  use  to  be  effective,  it  is  necessary  that  the  suppliers  and  users  of  metrics  data  understand 
the  purpose  of  metrics  use,  what  types  of  data  can  be  collected,  and  how  the  data  can  be  used.  Proj¬ 
ects  and  organizations  that  expect  to  benefit  from  metrics  must  be  willing  to  commit  significant 
resources  to  metrics  implementation  and  use.  They  must  be  willing  to  take  time  to  identify  issues, 
risks,  and  information  needs  and  to  determine  what  can  be  measured  to  address  them.  In  addition, 
they  must  be  serious  about  developing  a  metrics  program  plan  that  precisely  defines  metrics  and 
describes  in  detail  the  data  collection,  analysis,  and  interpretation  processes. 
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Appendix  A — Metrics  Calculations 


(a)  Plan  vs.  Actual  Use  Cases  Completed 

Cum.  Plan  =  Previous  Week  Cum.  Plan  +  CRP  Plan 
Cum.  Actual  =  Previous  Week  Cum.  Actual  +  CRP  Actual 

(b)  Plan  vs.  Actual  Classes  Completed 

Cum.  Plan  =  Previous  Week  Cum.  Plan  +  CRP  Plan 
Cum.  Actual  =  Previous  Week  Cum.  Actual  +  CRP  Actual 

(c)  Number  of  Attributes  in  a  Class 

Cum.  Classes  =  Previous  Week  Cum.  Classes  +  CRP  #  Classes 
Cum.  Attributes  =  Previous  Week  Cum.  Attributes  +  CRP  #  Attributes 
Ratio  =  CRP  #  Classes  /  CRP#  Attributes 
Cum.  Ratio  =  Cum.  Classes  /  Cum.  Attributes 

(d)  Number  of  Methods  in  a  Class 

Cum.  Classes  =  Previous  Week  Cum.  Classes  +  CRP  #  Classes 
Cum.  Methods  =  Previous  Week  Cum.  Methods  +  CRP  #  Methods 
Ratio  =  CRP  #  Classes  /  CRP  #  Methods 
Cum.  Ratio  =  Cum.  Classes  /  Cum.  Methods 

(e)  Number  of  Scenarios  in  a  Use  Case 

Cum.  Use  Cases  =  Previous  Week  Cum.  Use  Cases  +  CRP  #  Use  Cases 
Cum.  Scenarios  =  Previous  Week  Cum.  Scenarios  +  CRP  #  Scenarios 
Ratio  =  CRP  #  Use  Cases  /  CRP  #  Scenarios 
Cum.  Ratio  =  Cum.  Use  Cases  /  Cum.  Scenarios 

(f)  Added,  Deleted  and  Modified  Use  Cases 
Actual  =  Base  +  CRP  Added  -  CRP  Deleted 
Cum.  Plan  =  Previous  Week  Cum.  Plan  +  CRP  Plan 
Cum.  Actual  =  Previous  Week  Cum.  Actual  +  Actual 
Chum  Ratio  =  (CRP  Modified  /  Cum.  Actual) 

(g)  Added,  Deleted  and  Modified  Classes 
Actual  =  Base  +  CRP  Added  -  CRP  Deleted 
Cum.  Plan  =  Previous  Week  Cum.  Plan  +  CRP  Plan 
Cum.  Actual  =  Previous  Week  Cum.  Actual  +  Actual 
Churn  Ratio  =  (CRP  Modified  /  Cum.  Actual) 

(h)  Plan  vs.  Actual  Methods  Completed 

Cum.  Plan  =  Previous  Week  Cum.  Plan  +  CRP  Plan 
Cum.  Actual  =  Previous  Week  Cum.  Actual  +  CRP  Actual 
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(i)  Added,  Deleted  and  Modified  Methods 
Actual  =  Base  +  CRP  Added  —  CRP  Deleted 
Cum.  Plan  =  Previous  Week  Cum.  Plan  +  CRP  Plan 
Cum.  Actual  =  Previous  Week  Cum.  Actual  +  CRP  Actual 
Churn  Ratio  =  (CRP  Modified  /  Cum.  Actual) 

(j)  Plan  vs.  Actual  Attributes  Completed 

Cum.  Plan  =  Previous  Week  Cum.  Plan  +  CRP  Plan 
Cum.  Actual  =  Previous  Week  Cum.  Actual  +  CRP  Actual 

(k)  Added,  Deleted  and  Modified  Attributes 
Actual  =  Base  +  CRP  Added  —  CRP  Deleted 
Cum.  Plan  =  Previous  Week  Cum.  Plan  +  CRP  Plan 
Cum.  Actual  =  Previous  Week  Cum.  Actual  +  CRP  Actual 
Churn  Ratio  =  (CRP  Modified  /  Cum.  Actual) 

(l)  Type  of  Method  in  Class 

Cum.  Private  =  Previous  Week  Cum.  Plan  +  CRP  Plan 
Cum.  Protected  =  Previous  Week  Cum.  Actual  +  CRP  Actual 
Cum.  Public  =  Previous  Week  Cum.  Actual  +  CRP  Actual 

(m)  Plan  vs.  Actual  Milestone 

Total  Variance  =  (Actual  Days  -  Plan  Days)  +  Days  Late  Starting 
Cum.  Variance  =  Previous  Week  Cum.  Variance  +  Total  Variance 

(n)  Milestone  Slip  Ratio 

Variance  =  (Actual  Days  -  Plan  Days)  +  Days  Late  Starting 
Slip  Ratio  =  Variance  /  Plan  Days 

(o)  Use  Case  Traceability  Status 

Cum.  Use  Cases  =  Previous  Week  Cum.  Use  Cases  +  CRP  #  Use  Cases  Defined 

Cum.  Use  Cases  (UC)  Traced  =  Previous  Week  Cum.  Use  Cases  Traced  +  CRP  Use  Cases 

Traced  to  a  Higher  Requirement  +  CRP  Derived  Requirements 

(p)  Class  Traceability  Status 

Cum.  Classes  =  Previous  Week  Cum.  Classes  +  CRP  #  Classes  Defined 

Cum.  Classes  Traced  =  Previous  Week  Cum.  Classes  Traced  +  CRP  Classes  Traced  to  Use  Cases 
+  Derived  Class 

(q)  Integration  Test  Traceability  Status 

Cum.  Classes  =  Previous  Week  Cum.  Classes  +  CRP  #  Classes  Defined 

Cum.  Classes  Traced  =  Previous  Week  Cum.  Classes  +  CRP  Classes  Traced  to  Integration  Test 
Ca.ses 

(r)  Functional  Test  Traceability  Status 

Cum.  Use  Cases  =  Previous  Week  Cum.  Use  Cases  +  CRP  #  Use  Cases  Defined 

Cum.  Use  Cases  Traced  =  Previous  Week  Cum.  Use  Cases  Traced  +  CRP  Use  Cases  Functional 

Test  Cases  +  Derived  Requirements 
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(s)  Plan  vs.  Actual  Classes  that  have  Successfully  Passed  Integration  Test 
Cum.  Plan  =  Previous  Week  Cum.  Plan  +  CRP  Plan 

Cum.  Actual  =  Previous  Week  Cum.  Actual  +  CRP  Actual 

(t)  Plan  vs.  Actual  Use  Cases  that  have  Successfully  Passed  Functional  Test 
Cum.  Plan  =  Previous  Week  Cum.  Plan  +  CRP  Plan 

Cum.  Actual  =  Previous  Week  Cum.  Actual  +  CRP  Actual 

(u)  Ratio  of  Use  Cases  in  Build 

CRP  Use  Case  Integ.  Slip  Ratio  =  CRP  Build  Actual  Use  Cases  /  CRP  Build  Plan  Use  Cases 

(v)  Ratio  of  Classes  in  Build 

CRP  Class  Integ.  Slip  Ratio  =  CRP  Build  Actual  Classes  /  CRP  Build  Plan  Classes 
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Appendix  C — 00  Technique  Primer 


C.1  The  Evolution  of  Software  Development. 

Early  computers  were  strong  boxes  with  weak  brains.  These  early  computers  were  expected  to  per¬ 
form  small,  specific  tasks.  A  programmer’s  job  was  to  write  code  that  performed  that  small  task.  It 
took  little,  if  any,  analysis  to  figure  out  how  to  solve  the  problem.  As  computer  capacity  grew,  the 
number  of  tasks  a  computer  was  required  to  perform  increased,  but  each  individual  task  remained 
relatively  simple. 

Programming  then  evolved  from  a  task  orientation  to  a  system  orientation.  The  software  system  inte¬ 
grates  many  individual  tasks  into  a  single  application.  The  integrated  tasks  are  required  to  share  data, 
communicate,  and  otherwise  automate  the  operations  that  were  previously  run  manually  one  piece  at 
a  time.  Programming  systems  is  more  difficult  than  programming  tasks.  Programmers  did  not  have 
the  experience  or  tools  to  think  about  systems.  Furthermore,  the  complexity  of  the  software  sur¬ 
passed  the  analysis  abilities  of  most  software  developers. 

Flowcharts  were  the  first  widely  used  analysis  tool.  A  flow  chart  depicts  the  functional  flow  of  a 
system.  The  process  of  flowcharting  allows  developers  to  think  about  and  solve  problems  on  paper 
before  writing  code.  As  an  added  benefit,  flow  charts  are  useful  to  the  people  tasked  with  maintain¬ 
ing  systems. 

Structured  programming  in  higher  order  languages  (HOL)  replaced  flowcharts  as  the  design  tool  of 
choice.  Early  software  engineering  researchers  convinced  programmers  that  removing  line  numbers, 
lining  up  an  “if’  with  its  “endif ’,  and  eliminating  “goto”  statements  would  eradicate  bad  buggy  soft¬ 
ware.  Structured  programming  helped  a  little;  however,  bad  software  continued  to  be  produced. 

Next  came  the  structured  analysis  (SA)  techniques,  and  many  tool  vendors  supplied  design  decompo¬ 
sition  tools  to  provide  a  structured  mechanism  to  document  the  system  to  the  level  at  which  code 
could  be  developed.  The  thought  was  that  because  a  coherent  cohesive  design  had  been  developed 
from  the  “top  down,”  there  would  be  a  high  probability  that  the  code  could  integrate  successfully 
from  the  “bottom  up.”  The  structured  analysis  movement  led  to  an  integration  philosophy  of  either 
“top  down”  or  “bottom  up.”  During  the  stmctured  analysis  era,  the  integration  philosophy  was  influ¬ 
enced  by  the  design  decomposition  methodology. 

The  state  of  the  practice  has  recently  evolved  to  object  orientation.  This  design  mechanism  focuses 
on  data  rather  than  functions  and  produces  models  that  represent  a  “real  world”  view  of  the  problem. 
Object  orientation  provides  a  more  intuitive  approach  to  decomposition  and  a  less  rigid  approach  to 
integration.  Integration  in  the  OO  paradigm  is  principally  thread  or  function  based.  This  approach  is 
feasible  because  the  designs  are  based  on  data  integration. 


73 


As  with  any  adaptive  system,  the  future  evolutions  fix  some  of  the  inadequacies  in  prior  implementa- 
tions.  Object  technology  is  no  different.  Specifically,  object  technology  was  designed  to  address  the 
inadequacies  experienced  in  developing  large  software  systems.  These  systems  are  characterized  as 
applications  that  exhibit  a  rich  set  of  behaviors.  Some  characteristics  of  large  software  systems 
include: 

•  Complex  problem  domain 

•  Difficulty  managing  the  development  process 

•  Required  system  flexibility 

•  Difficulty  characterizing  the  system 

Failure  to  manage  the  complexity  of  large  software  systems  results  in  projects  that  are  late,  over 
budget,  and  deficient  in  meeting  their  stated  requirements. 

Object  technology  was  targeted  to  address  the  known  shortcomings  inherent  in  the  development  of 
large  software  systems.  Due  to  the  risks  in  developing  large  complex  systems,  it  became  imperative 
to  implement  object  technology  in  order  to  mitigate  their  risks.  Since  complexity  in  large  software 
systems  will  not  decrease,  software-developing  organizations  must  learn  to  adapt  to  it  by  imposing  a 
rigorous  design  approach. 

There  are  two  distinct  aspects  of  applying  object-oriented  technologies.  The  first  is  a  methodology 
for  defining  the  design.  The  second  is  a  philosophy  for  managing  the  life  cycle  of  the  project.  Each 
of  these  will  be  discussed  in  the  subsequent  sections. 


C.2  Comparison  of  the  OO  Methodology  to  the  SA  Method 

A  software  development  methodology  can  be  simply  defined  as  a  set  of  procedures  that  are  followed 
from  the  beginning  to  the  completion  of  the  software  development  process.  Since  the  1970s,  there 
has  been  a  proliferation  of  unique  software  design  methodologies  developed  to  solve  different  types 
of  application  problems.  Even  though  these  design  methodologies  have  evolved  to  respond  to  a  spe¬ 
cific  application  domain,  there  are  many  common  characteristics.  The  common  characteristics 
include:  (1)  a  mechanism  for  the  translation  of  information  domain  representation  into  design  repre¬ 
sentation,  (2)  a  notation  for  representing  functional  components  and  their  interfaces,  (3)  heuristics  for 
refinement  and  partitioning,  and  (4)  guidelines  for  quality  assessments.  These  characteristics  will  be 
used  to  contrast  OO  and  SA  methodologies  in  the  following  sections. 

The  Structured  Analysis  (SA)  methodology  is  a  dataflow-oriented  design  approach.  SA  utilizes  a 
technical  graphics  “language”  and  a  set  of  procedures  and  management  guidelines  to  implement  the 
language.  This  language  is  called  the  language  of  Structured  Analysis.  The  procedures  for  the  SA 
language  are  similar  to  the  guidelines  used  for  engineering  blueprint  systems.  Each  SA  diagram  is 
drawn  on  a  single  page  and  contains  three  to  six  nodes  with  interconnecting  arcs.  There  are  two  kinds 
of  SA  diagrams  -  the  activity  diagram  and  the  data  diagram.  [DEMARCO] 
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The  SA  methodology  provides  a  precise  and  concise  representation  scheme  and  a  set  of  techniques  to 
graphically  define  complex  system  requirements.  Figure  C.2-1  provides  a  representation  of  the  nota¬ 
tion  used  for  the  SA  methodology.  There  is  top-down  decomposition  with  clear  decomposition  for 
input,  output,  and  control  mechanisms  for  each  node.  It  is  beneficial  to  segregate  the  data  and  the 
activities  into  two  diagrams  so  that  the  diagrams  are  not  cluttered.  The  notation  also  distinguishes 
between  control  data  and  input  data.  However,  in  systems  where  many  hierarchical  diagrams  are 
involved,  the  additional  control  information  on  the  diagrams  can  make  it  difficult  to  understand, 
[YOURDON] 

S A  offers  two  quality  criteria  for  evaluating  software  design,  one  for  the  software  system  level  and 
one  for  the  module  level.  The  software  system-level  criterion  measures  the  connections  to  other 
modules  (coupling),  and  the  module-level  criterion  measures  the  intra-module  unity  (cohesion). 
Coupling  provides  a  way  of  evaluating  the  inter-dependencies  between  modules.  Since  modules  are 
the  building  blocks  of  a  software  system,  their  relationships  will  determine  how  well  the  system  can 
be  maintained  or  changed.  If  the  modules  are  highly  interdependent  on  one  another,  it  will  be  more 
difficult  to  make  changes  to  one  module  without  affecting  the  others.  Conversely,  if  the  modules  are 
highly  independent  from  one  another,  it  will  be  easy  to  maintain,  and  changes  can  be  made  on  one 
module  without  affecting  the  others.  Cohesion  provides  a  way  of  evaluating  the  functional  connec¬ 
tions  among  a  module’s  processing  elements.  The  most  desirable  cohesion  is  one  where  a  module 
performs  a  single  task  with  individual  data  elements.  The  least  desirable  cohesion  is  one  where  a 
module  performs  a  few  different  tasks  with  unrelated  data  structures.  A  good  system  design  will  have 
strong  cohesion  and  weak  coupling. 


Figure  C.2- 1 .  Structured  analysis  model  notation. 
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Object-Oriented  Analysis  (OOA)  and  Design  (OOD)  create  a  model  of  the  real  world  and  map  it  to 
the  software  structure.  00  technique  model  the  problem  in  terms  of  its  data  (i.e.,  objects  and  classes) 
and  the  operations  performed  on  them.  Objects  represent  concrete  entities,  which  are  instances  of  one 
or  more  classes.  Objects  encapsulate  data  attributes,  which  can  be  data  structures  or  just  attributes, 
and  operations,  which  are  procedures.  Operations  contain  methods,  which  are  program  code  that 
operates  on  the  attributes.  A  class  is  a  set  of  objects  that  share  a  set  of  common  structure  and  behav¬ 
ior.  A  class  represents  a  type,  and  an  object  is  an  instance  of  a  class.  The  derivation  of  subclasses 
from  a  class  is  called  inheritance.  Relationships  describe  the  dependencies  between  classes  and 
objects. 

OO  requirements  analysis  and  design  start  at  the  top-level  of  the  software  system  by  identifying  the 
objects  and  classes,  their  relationships  to  other  classes,  their  major  attributes,  their  inheritance  rela¬ 
tionships.  Next  a  class  hierarchy  is  derived.  The  basic  building  blocks  for  00  are  the  mechanisms 
for  depicting  the  data  structure,  specifying  the  operation  and  invoking  the  operation.  Figure  C.2-2 
represents  an  example  00  diagram. 

A  detailed  design  representation  is  obtained  by  extracting  the  objects  that  are  available  from  each 
class  and  defining  their  relationships  to  each  of  the  other  objects.  Identifying  classes  and  objects 
creates  data  abstractions;  modules  are  defined  and  structures  for  software  are  established  by  assigning 
operations  to  the  data;  and  interfaces  are  described  by  developing  a  mechanism  for  using  the  objects. 

Once  the  objects  have  been  identified,  the  sets  of  operations  that  act  on  the  objects  are  defined.  There 
are  basically  three  types  of  operations;  those  that  manipulate  data,  those  that  perform  computation, 
and  those  that  monitor  an  object.  Defining  the  object  and  its  operations  alone  is  not  enough  to  derive 
the  program  structure.  The  interface  that  exists  between  the  overall  structure  and  objects  must  be 
identified  and  defined.  All  of  these  elements  are  integrated  into  a  program-like  constmct. 


Figure  C.2-2.  Object-oriented  model  notation. 
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The  Object-Oriented  quality  criteria  for  evaluating  software  design  include  five  attributes:  Coupling, 
Cohesion,  Sufficiency,  Completeness,  and  Primitiveness.  Both  coupling,  the  connections  to  other 
modules,  and  cohesion,  the  intra-module  unity,  have  been  borrowed  from  structured  analysis. 

Closely  related  to  the  ideas  of  coupling  and  cohesion  are  the  criteria  that  a  class  or  module  should  be 
sufficient,  complete,  and  primitive.  Sufficiency  means  that  the  class  or  module  captures  enough  char¬ 
acteristics  of  the  abstraction  to  permit  meaningful  and  efficient  interaction.  Completeness  means  that 
the  interface  of  the  class  or  module  captures  all  of  the  meaningful  characteristics  of  the  abstraction. 
Where  sufficiency  implies  a  minimal  interface,  completeness  implies  the  interface  covers  all  aspects 
of  the  abstraction.  Primitiveness  applies  to  operations  on  data.  An  operation  is  primitive  if  additional 
functionality  can  be  implemented  only  though  access  to  the  underlying  representation.  [BOOCH] 

In  summary,  both  SA  and  OO  provide  a  means  for  generating  a  software  design.  A  summary  of  the 
key  points  of  each  of  the  two  methodologies  is  presented  in  Table  C.2-1.  This  table  is  organized 
around  the  common  methodology  characteristics  discussed  at  the  beginning  of  this  section. 

Both  the  SA  and  OO  methodology  for  developing  software  are  well  defined  and  have  been  proven 
useful  in  many  domains.  A  comparison  of  these  two  methodologies  is  presented  in  Figure  C.2-3. 

One  of  the  features  that  OO  provides  that  distinguishes  it  from  SA  is  a  focus  on  the  real  world.  This 
approach  makes  the  design  models  fully  understandable  by  the  domain  experts.  Another  feature  is 
the  mapping  of  the  real-world  model  to  the  software.  This  mapping  is  accomplished  by  domain- 
experienced  engineers  and  provides  full  traceability  between  the  “what”  is  needed  and  the  “how”  of 
implementation.  Finally,  the  OO  methodology  provides  a  data  centric  orientation.  This  orientation  is 
the  most  intuitive  approach  for  many  of  the  data  centric  systems  under  development  today. 


Table  C.2-1.  Comparison  of  Characteristics  of  the  Structured  Analysis  and  Object-Oriented  Techniques. 
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Figure  C.2-3.  Comparison  of  structured  analysis  and  object-oriented  approaches. 


One  of  the  features  of  the  SA  approach  that  distinguishes  it  from  the  00  methodology  is  a  precise 
and  complete  model  of  the  computing  system.  This  approach  provides  the  programmers  with  a  fully 
comprehensible  model  to  Implement.  Another  feature  of  the  SA  approach  is  that  it  provides  a  hierar¬ 
chical  model  that  hides  unnecessary  detail  from  the  programmers  until  absolutely  necessary.  Finally, 
the  SA  approach  details  the  processes  that  work  on  the  data. 


C.3  Contrast  SA  Life  cycle  to  OO  Life  cycle 

Software  has  been  developed  for  the  last  two  decades  using  the  traditional  SA  approach  or  its  varia¬ 
tions.  Each  variation  created  a  new  set  of  problems  for  project  management.  With  the  emergence  of 
object-orientated  techniques  there  has  been  a  radical  shift  in  the  development  approach. 

In  parallel  with  the  emergence  of  OO  techniques,  new  approaches  to  the  software  life  cycle  have 
emerged.  The  software  development  life  cycle  can  be  characterized  as  either  a  “once-through”  water¬ 
fall  or  iterative.  There  are  currently  several  types  of  iterative  life-cycle  models  in  use,  e.g.,  incre¬ 
mental,  evolutionary,  and  spiral.  Originally,  SA  was  used  with  the  waterfall  or  incremental  models. 
The  OO  methodology  is  more  suited  to  the  newer  evolutionary  or  spiral  life  cycles,  although  any  of 
the  life-cycle  models  can  be  used  with  either  type  of  methodology.  Figure  C.3-1  summarizes  the 
mapping  of  life-cycle  models  to  methodology. 

In  the  SA  approach,  software  is  developed  using  a  top-down  functional  decomposition  strategy, 
starting  with  a  high-level  view  and  progressively  refining  this  view  into  a  more  detailed  design. 
Implementation  and  integration  are  frequently  accomplished  using  a  “top  down”  or  “bottom  up” 
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v 

Iterative 
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V 
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Figure  C.3-1.  Life  eycle  to  methodology  mapping. 
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integration  approach.  The  SA  life-cycle  activities  comprise  three  main  phases:  analysis,  design,  and 
implementation,  each  executed  a  single  time  for  any  given  iteration.  Figure  C.3-2  depicts  the 

waterfall  or  “once  through”  life-cycle  model,  which  contains  these  three  phases  of  activities  in 
sequence.  In  the  iterative  life  cycle  models  most  applicable  to  SA  (iterative,  evolutionary,  and  some 
spiral  instantiations),  each  iteration  consists  of  the  activities  shown  in  Figure  C.  1.3-2  or  of  specific 
subsets  of  these  activities. 

In  a  waterfall  approach,  there  is  a  lot  of  emphasis  on  “the  specs”  (i.e.,  the  problem-space  description) 
and  getting  them  correct,  complete,  polished,  and  signed-off.  In  the  iterative  process,  the  software 
product  takes  precedence.  The  software  architecture  (i.e.,  the  solution-space  description)  drives  early 
life-cycle  decisions.  Customers  do  not  buy  specifications;  it  is  the  software  product  that  is  the  main 
focus  of  attention  throughout,  with  both  specifications  and  software  evolving  in  parallel.  This  focus 
on  “software  first”  impacts  the  various  teams.  For  example,  in  a  waterfall  development,  testers  may 
be  used  to  receiving  complete,  stable  specifications,  well  in  advance  of  the  start  of  testing.  In  an 
iterative  development,  the  testers  have  to  begin  working  at  once  on  subsets  of  the  software,  with 
specifications  and  requirements  that  are  still  evolving.  [KRUCHTENl] 

In  contrast,  since  the  OO-specific  approach  centers  around  modeling  the  “real  world”  in  terms  of 
objects  that  encapsulate  data  and  operations,  the  OO  life  cycle  supports  the  new  programming  phases 
of  Inception,  Elaboration,  Construction,  and  Transition.  During  the  Inception  Phase,  the  “good  idea” 
is  defined,  and  the  end-product  vision  is  developed.  The  Inception  Phase  is  concluded  with  the  life- 
cycle  objective  (ECO)  milestone.  The  Elaboration  Phase  consists  of  planning  the  necessary  activities 
and  required  resources,  specifying  the  requirements,  and  designing  the  architecture.  The  life-cycle 
architecture  (LCA)  milestone  concludes  the  Elaboration  Phase.  The  Construction  Phase  develops  the 
product  and  evolves  the  vision  until  it  is  ready  for  delivery  to  its  user  community.  The  Initial  Opera¬ 
tion  Capability  (IOC)  milestone  concludes  the  Construction  Phase.  The  Transition  Phase  provides  for 
the  transfer  of  the  product  to  the  users.  This  includes  manufacturing,  delivering,  and  training,  and 
supporting  and  maintaining  the  product  until  the  users  are  satisfied.  The  Transition  Phase  is  con¬ 
cluded  by  the  Final  Operational  Capability  (FOC),  which  also  concludes  the  life  cycle.  This  phase 
relationship  is  depicted  in  Figure  C.3-3. 


Figure  C.3-2.  Waterfall  or  “Once  Through”  software  life  cycle  model. 
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Adapted  from:  The  Rational  Unified  Process  -  An  Introduction.  Krutchten,  Philippe,  Addison-Wesley,  1999. 


Figure  C.3-3.  Iterative  Development  ~  shifting  focus  across  the  cycle. 

In  Figure  C.3-3,  each  iteration  follows  a  pattern  similar  to  the  waterfall  approach,  and,  therefore,  it 
contains  the  activities  of  requirements  elicitation  and  analysis,  of  design  and  implementation,  and  of 
integration  and  test.  However,  from  one  iteration  to  the  next  and  from  one  phase  to  the  next,  the 
emphasis  on  the  various  activities  will  change.  Figure  C.3-4  shows  the  relative  emphasis  of  the  vari¬ 
ous  types  of  activities  over  time.  In  the  Inception  Phase  the  emphasis  is  mainly  on  understanding  the 
overall  requirements  and  determining  the  scope  of  the  development  effort.  In  the  Elaboration  Phase, 
the  focus  is  on  requirements,  with  some  design  and  implementation  aimed  primarily  at  prototyping. 
During  the  Construction  Phase  the  emphasis  is  on  design  and  implementation.  In  the  Transition 
Phase  the  focus  is  on  ensuring  that  the  system  has  the  right  level  of  quality  to  meet  the  objectives.  In 
this  way,  the  product  evolves  from  initial  conception  to  delivery  through  numerous  iterations  of 
requirements,  design,  code,  integration,  and  maintenance.  (An  example  of  an  OO-specific  life-cycle 
model  would  be  that  which  is  described  in  the  Rational  Unified  Process  (RUP).)  [RATIONAL] 
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Figure  C.3-4.  Comparison  of  waterfall  and  iterative  life  cycle  models. 
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In  summary,  both  the  Waterfall  and  Iterative  life  cycles  for  developing  software  are  well  defined  and 
have  been  proven  useful  in  many  domains.  A  comparison  of  these  two  life  cycles  is  presented  in  Fig¬ 
ure  C.3-4.  Some  of  the  benefits  of  the  waterfall  life  cycle  are  that  it  is  conceptually  easy  to  under¬ 
stand  and  can  be  applied  effectively  to  many  problems.  Another  benefit  of  the  waterfall  approach  is 
that  it  allows  for  a  simple  determination  of  how  much  it  will  cost  to  accomplish  the  job.  There  are 
several  major  benefits  to  the  Iterative  life  cycles  described  above.  These  include  (1)  early  risk  miti¬ 
gation,  (2)  better  accommodation  of  changes,  (3)  potential  for  better  exploitation  of  reuse,  and  (4) 
incorporation  of  lessons  learned  from  previous  iterations. 
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Appendix  D — Acquisition  and  Development  Metrics  Planning 


The  acquirer  and  the  developer  both  have  significant  roles  to  play  in  developing  and  using  an  effec¬ 
tive  metrics  program.  While  metrics  use  is  most  often  thought  of  as  the  act  of  collecting  and  analyz¬ 
ing  data,  software  measurement  encompasses  a  number  of  other  activities  as  well,  including: 


•  Selecting  metrics. 

•  Developing  a  plan  and  process  for  implementing  the  metrics  and  for  making  changes  to 
the  metrics  program. 

•  Collecting,  calculating,  analyzing,  and  reporting  the  metrics. 

•  Applying  the  metrics  to  identify  and/or  assess  issues,  risks,  or  problems. 

•  Using  the  results  of  these  assessments  to  guide  decisions  and  actions  and  track  the  effects 
of  decisions  and  actions. 


There  are  tasks  for  both  the  acquirer  and  developer  in  each  of  these  activities. 


D.1  The  Acquirer’s  Role 

The  acquirer’s  role  encompasses  the  following  major  tasks: 

1 .  Determining  the  quantitative  data  (metrics)  needed  for  the  acquirer's  program  insight 

The  acquirer  should  develop  a  list  of  known  issues,  risks,  problems,  and  milestone/ 
review/IPT  events  for  the  program’s  software  effort  and  identify  the  types  of  data  that 
will  give  relevant  insight.  Where  possible  (depending  upon  the  acquisition  phase  and  the 
degree  of  interaction  between  the  acquirer  and  developer),  the  acquirer  and  developer 
should  work  together  on  this  task. 

2.  Obtaining  metrics  planning  information  and  metrics  data  from  the  developer 

The  acquirer  should  ensure,  through  contractual  means,  that  the  developer  is  motivated  to 
provide  metrics  plans  and  data  to  the  acquirer.  The  preferred  approach  (acquisition  strat¬ 
egy  permitting)  is  to  explicitly  require  the  developer  to  deliver  metrics  plans  and  periodic 
metrics  reports.  Section  D.3,  Supplying  Metrics  Data,  discusses  this  further.  If  such  con¬ 
tractual  requests  are  not  allowed,  and  a  capability  evaluation  [TROUP]  is  performed,  it 
may  be  possible  to  obtain  metrics-planning  information  in  an  SDP  via  appropriate  tailor¬ 
ing  of  the  evaluation  instrument.  If  neither  of  these  approaches  applies  to  a  program,  it 
will  be  necessary  to  work  directly  with  the  developer  to  encourage  metrics  use  and  the 
sharing  of  metrics  information. 
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3.  Creating  a  plan  for  reviewing  the  developer’s  metrics  plan  and  analyzing  data 


The  acquirer  should  assign  responsibility  for  reviewing  metrics  plans  and  data,  and  ensuring 
that  the  assigned  staff  has  the  appropriate  expertise  to  understand  the  information.  Such 
expertise  includes  both  software  engineering  and  program  knowledge.  Training  or  briefings 
should  be  supplied  at  the  executive  and  technical  level  as  appropriate  in  preparation  for 
analyzing  and  applying  the  data.  The  acquirer’s  plan  should  describe  its  analysis  process  for 
metrics  data  obtained  from  the  contractor,  including  an  approximate  analysis  schedule,  the 
resources  and  skills  required  to  perform  the  analysis,  a  list  of  the  high-level  steps  in  the 
analysis  procedure,  the  format  for  reporting  analysis  results,  and  the  action  to  be  taken  based 
on  the  information  in  the  analysis  reports. 

4.  Reviewing  the  developer’s  metrics  program  plan 

The  developer  and  acquirer  should  work  together  as  much  as  possible  during  develop¬ 
ment  and  maintenance  of  the  metrics  program  plan.  Where  possible,  the  acquirer  should 
have  a  major  role  in  the  metrics  selection  activity  and  at  least  a  review  role  in  the  metrics 
definition  activity.  The  acquirer  should  assign  personnel  with  software  engineering  and 
program  knowledge  to  evaluate  the  plan  to  ensure  that  it  addresses  key  program  objec¬ 
tives,  issues,  and  risks,  and  that  the  selected  metrics  set  covers  all  key  software  engi¬ 
neering  processes,  products,  and  resources.  The  adequacy  of  funding  and  personnel  that 
the  developer  allocates  to  the  metrics  effort  should  also  be  assessed. 

As  part  of  this  task,  the  acquirer  should  document  its  assessment  of  the  developer’s  met¬ 
rics  approach,  metrics  set,  and  metrics  definitions,  identifying  any  weaknesses  or  omis¬ 
sions.  Even  if  this  information  is  not  supplied  to,  or  used  by,  the  developer,  it  wilt  be 
useful  to  the  acquisition  personnel  who  must  analyze  the  metrics  data. 


5.  Analyzing  the  developer’s  metrics 

The  acquirer  should  perform  its  own  analysis  of  the  developer’s  metrics  data.  First,  an 
assessment  of  the  validity  of  the  data  should  be  performed  to  ensure  its  currency,  consis¬ 
tency,  and  accuracy.  Then,  the  data  should  be  analyzed  and  interpreted  to  identify  and 
track  the  status  of  problems,  risks,  and  issues.  The  analysis  should  also  use  the  metrics 
data  to  assess  the  effectiveness  of  previous  preventive  and  corrective  actions. 

6.  Supplying  feedback  for  needed  changes  to  the  metrics  activity 

If  shortcomings  are  discovered  in  the  metrics  set  or  the  metrics  program  itself,  or  if  new 
metrics  are  needed,  the  developer  should  be  notified  so  that  appropriate  modifications  can 
be  made.  Note  that  without  sufficient  contractual  motivation,  the  developer  will  likely  be 
reluctant  to  make  modifications,  especially  if  they  appear  to  be  costly  or  if  the  developer 
does  not  expect  to  benefit  from  them.  Similarly,  the  acquirer  may  find  deficiencies  in  its 
own  metrics  plan,  and  should  modify  it  accordingly. 
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7,  Ensure  that  metrics  results  are  fed  back  into  development  so  that  corrections/adjustments 
can  be  made. 

All  too  frequently,  metrics  data  is  collected  and  reported  but  not  actually  used  in  manag¬ 
ing  the  project.  Both  the  developer  and  the  acquirer  must  work  to  ensure  that  corrective 
actions  are  performed  based  on  the  analysis  of  the  metrics  data. 

D.2  The  Developer’s  Role 

The  developer  has  tasks  to  perform  that  parallel  those  of  the  acquirer.  These  are  shown  in  Table  D.2- 
1.  At  a  minimum,  the  developer’s  tasks  include  preparing  a  metrics  program  plan  in  accordance  with 
the  instructions  in  the  contract,  allocating  resources  and  providing  any  needed  training  to  implement 
the  plan,  implementing  the  plan,  performing  all  data  collection,  analysis,  and  reporting  activities,  and 
using  the  results  for  preventive  and  corrective  action. 


Table  D.2-1.  Metrics  Program  Planning  Tasks 


# 

Acquirer 

Developer 

1 

Determine  metrics  needed  for  acquisition 
insight 

Determine  metrics  needed  for  development 
management 

2 

Request  metrics  planning  information  and 
metrics  data  from  the  developer 

Create  a  metrics  plan,  data  collection  and 
analysis  process,  collection  and  reporting 
schedule  and  format  for  reporting  to  devel¬ 
opment  management. 

Respond  to  the  request  by  providing  the 
acquirer  with  a  metrics  program  information 

3 

Create  a  plan  for  reviewing  the  developer’s 
metrics  plan  and  analyzing  metrics  data 

Incorporate  the  acquirer’s  review/analysis 
plans  into  the  metrics  program  plan 

4 

Evaluate  the  developer’s  metrics  program 
plan 

Revise  the  metrics  program  plan,  as 
appropriate 

5 

Analyze  the  developer’s  metrics  data  and 
provide  analysis  results  to  developer. 

Implement  the  metrics  plan,  analyzing  and 
using  data  in  preventive  and  corrective 
action,  using  the  data  in  process  improve¬ 
ment,  and  supplying  data  to  the  acquirer  for 
analysis 

Respond  to  analysis  results  from  acquirer 

6 

Supply  feedback  to  the  developer  on  needed 
changes  to  the  metrics  activity 

Analyze  metrics  program  for  needed 
improvements  and  improve  metrics  process 
accordingly 

Incorporate  developer  process  improvement 
analysis  and  acquirer’s  feedback  as 
appropriate 

85 


The  developer’s  metrics  program  plan  should  address  the  topics  in  Table  D.2-2,  These  topics  were 
developed  based  on  material  from  Metrics  for  Software-Intensive  Mission  Critical  Computer 
Resource  Systems  [COSTELLO]. 


Table  D.1-2.  Topics  for  the  Metrics  Program  Plan 

Topics  for  the  Metrics  Program  Plan  -  _  _ _ 

1.  Introduction 

2.  Project  and  Organizational  Context 
Project  technical  characteristics 

Project  and  organization  management  characteristics 
Project  and  organization  relevant  past  experience 

Intended  management  use  of  the  metrics  information  to  assess  and  improve  the  software  system  product  and  the  proc¬ 
esses  used  to  generate  the  product 

Project-specific  and  organization-wide  issues,  risks,  and  information  needs  to  be  addressed  with  metrics 

3.  Roles  and  Responsibilities 

Organization  and  individuals  responsible  for  the  metrics  program  overall 

Roles  and  responsibilities  for  metrics  selection,  definition,  planning,  evaluation,  and  improvement 
Roles  and  responsibilities  for  metrics  collection,  analysis,  reporting,  and  feedback 
Roles  and  responsibilities  for  metrics  archival  and  configuration  management 
Measurement  interfaces 

Project  software  development  organization  to  acquirer,  user 
Project  software  development  organization  to  subcontractor(s) 

Project  software  development  organization  to  project  software  process  group  and/or  overall  devel¬ 
opment  organization  (the  latter  interface  may  be  via  the  software  process  group) 

Software-level  metrics  personnel  to  systems-level  metrics  personnel 
Software  metrics  personnel  to  software  QA,  CM,  safety,  security,  RMA,  etc.  personnel 
Potential  impediments  to  effective  metrics  use  and  how  these  will  be  addressed 

4.  General  Approach 

General  procedures  for  collection,  reporting,  and  data  archival/configuration  management 

Tools  for  collection,  reporting,  and  data  archival/configuration  management;  and  tool  interfaces  (automated  or  manual), 
where  applicable 

Overall  aggregation  structures  applicable  in  data  collection  and  “roll  up” 

5.  Measurable  Parameters 

Products,  processes,  and  resources  relevant  to  the  life  cycle  and  their  attributes  to  measure  and  to  address  identified 
problems,  risks,  issues,  and  information  needs 

Product,  process,  and  resource  characteristics  needed  to  make  these  attributes  measurable  (e.g.,  structuring  require¬ 
ments  so  that  they  are  individually  countable 

Interfaces  to  the  system  level  for  the  software-related,  system-level  attributes  to  be  measured 
Interfaces  to  software  quality  and  specialty  engineering  disciplines  (e.g.,  CM,  QA,  safety,  security,  RMA) 

Phased  implementation  of  metrics,  if  applicable 

6.  Detailed  Metrics  Descriptions 
Metrics  Name 

Metric  Description 

Primitive  data  elements  --  How  defined.  How  and  when  collected 
Equations  for  calculating  the  metric 
Reporting  Format  -  Graphical  and  numeric  data 
Analysis  and  interpretation  guide 

7.  Metrics  Program  Evaluation  and  Improvement  Process 
Process  for  determining  when  improvements  are  needed 

Process  for  updating  metrics  set/definitions  while  maintaining  analysis  capability  on  previous  metrics  set 
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D.3  Supplying  Metrics  Data 

To  enable  the  acquirer  to  make  the  most  of  the  developer’s  metrics  program,  the  developer  should 
provide  the  acquirer  with  the  following  two  types  of  information:  (1)  planning  information  that 
describes  the  metrics  program  in  detail  and  (2)  specific  metrics  data  at  regular  reporting  intervals.  It 
cannot  be  assumed  that  the  developer  will  supply  the  above  information  and  reports  to  the  acquirer,  or 
even  that  the  developer  knows  what  constitutes  good  planning  information  or  a  complete  metrics 
report.  The  latter  might  occur  depending  on  where  the  developer  is  on  the  technology  transition  life¬ 
cycle  curve  and  the  technology  adoption  curve.  Therefore,  wherever  possible,  the  acquirer  must 
communicate  its  specific  metrics  needs  and  the  developer's  development  management  metrics  needs 
to  the  developer  in  an  explicit,  contractually  binding  form. 


D.3.1  Planning  Information 

Planning  information  consists  of  information  on  the  overall  approach  and  process  (as  described  in 
Table  D.  1  .-2)  including  complete  descriptions  of  each  metric 


D.3.2  Metrics  Reports 

Specific  metrics  reports  consist  of  graphical  and  numerical  data,  written  analysis,  and  data  in  elec¬ 
tronic  form.  Metrics  reports  should  contain  summary  data,  primitive  data,  and  interpretive  and  con¬ 
textual  information.  In  general,  high-level,  summary  data  should  be  reported  by  the  developer  and 
discussed  with  the  acquirer  monthly.  Primitive  (low-level)  data  should  be  reported  (or  made  avail¬ 
able)  monthly  in  electronic  form  to  facilitate  analysis  by  the  acquirer.  Interpretive  and  contextual 
information  should  be  supplied  as  required  in  order  to  understand  the  metric  report  being  presented. 

Interpretive  data  should  include  graphical  reports,  numerical  data  supplements,  and  written  analyses. 
Graphical  reports  must  contain  sufficient  information  so  that  they  are  not  misleading.  Numerical  data 
supplements  (e.g.,  in  tabular  form)  may  be  helpful  in  this  regard.  Written  analyses  should  be  deliv¬ 
ered  with  each  report.  These  should  explain  the  process  for  analyzing  the  metric;  differences  between 
the  expected  and  actual  values  for  the  metric,  if  any;  behavior  of  the  metric  in  the  context  of  other 
project  information  and  metrics;  and  recommended  actions  based  upon  the  analysis,  if  any. 
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LABORATORY  OPERATIONS 


The  Aerospace  Corporation  functions  as  an  “architect-engineer”  for  national  security  programs,  specializing  in 
advanced  military  space  systems.  The  Corporation’s  Laboratory  Operations  supports  the  effective  and  timely 
development  and  operation  of  national  security  systems  through  scientific  research  and  the  application  of 
advanced  technology.  Vital  to  the  success  of  the  Corporation  is  the  technical  staffs  wide-ranging  expertise  and 
its  ability  to  stay  abreast  of  new  technological  developments  and  program  support  issues  associated  with  rapidly 
evolving  space  systems.  Contributing  capabilities  are  provided  by  these  individual  organizations: 

Electronics  and  Photonics  Laboratory;  Microelectronics,  VLSI  reliability,  failure  analy¬ 
sis,  solid-state  device  physics,  compound  semiconductors,  radiation  effects,  infrared  and 
CCD  detector  devices,  data  storage  and  display  technologies;  lasers  and  electro- optics,  solid 
state  laser  design,  micro-optics,  optical  communications,  and  fiber  optic  sensors;  atomic 
frequency  standards,  applied  laser  spectroscopy,  laser  chemistry,  atmospheric  propagation 
and  beam  control,  LIDAR/LADAR  remote  sensing;  solar  cell  and  array  testing  and  evalua¬ 
tion,  battery  electrochemistry,  battery  testing  and  evaluation. 

Space  Materials  Laboratory:  Evaluation  and  characterizations  of  new  materials  and 
processing  techniques:  metals,  alloys,  ceramics,  polymers,  thin  films,  and  composites; 
development  of  advanced  deposition  processes;  nondestructive  evaluation,  component  fail¬ 
ure  analysis  and  reliability;  structural  mechanics,  fracture  mechanics,  and  stress  corrosion; 
analysis  and  evaluation  of  materials  at  cryogenic  and  elevated  temperatures;  launch  vehicle 
fluid  mechanics,  heat  transfer  and  flight  dynamics;  aerothermodynamics;  chemical  and 
electric  propulsion;  environmental  chemistry;  combustion  processes;  space  environment 
effects  on  materials,  hardening  and  vulnerability  assessment;  contamination,  thermal  and 
structural  control;  lubrication  and  surface  phenomena. 

Space  Science  Applications  Laboratory:  Magnetospheric,  auroral  and  cosmic  ray 
physics,  wave-particle  interactions,  magnetospheric  plasma  waves;  atmospheric  and 
ionospheric  physics,  density  and  composition  of  the  upper  atmosphere,  remote  sensing 
using  atmospheric  radiation;  solar  physics,  infrared  astronomy,  infrared  signature  analysis; 
infrared  surveillance,  imaging,  remote  sensing,  and  hyperspectral  imaging;  effects  of  solar 
activity,  magnetic  storms  and  nuclear  explosions  on  the  Earth’s  atmosphere,  ionosphere  and 
magnetosphere;  effects  of  electromagnetic  and  particulate  radiations  on  space  systems; 
space  instrumentation,  design  fabrication  and  test;  environmental  chemistry,  trace  detection; 
atmospheric  chemical  reactions,  atmospheric  optics,  light  scattering,  state-specific  chemical 
reactions  and  radiative  signatures  of  missile  plumes. 

Center  for  Microtechnology:  Microelectromechanical  systems  (MEMS)  for  space 
applications;  assessment  of  microtechnology  space  applications;  laser  micromachining; 
laser-surface  physical  and  chemical  interactions;  micropropulsion;  micro-  and  nanosatel¬ 
lite  mission  analysis;  intelligent  microinstruments  for  monitoring  space  and  launch  sys¬ 
tem  environments. 

Office  of  Spectral  Applications:  Multispectral  and  hyperspectral  sensor  development; 
data  analysis  and  algorithm  development;  applications  of  multispectral  and  hyperspectral 
imagery  to  defense,  civil  space,  commercial,  and  environmental  missions. 
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